Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expressions can be typed as open generic types #17121

Closed
JonHanna opened this issue Apr 26, 2016 · 9 comments
Closed

Expressions can be typed as open generic types #17121

JonHanna opened this issue Apr 26, 2016 · 9 comments

Comments

@JonHanna
Copy link
Contributor

The likes of Expression.Default(typeof(List<>)), Expression.Constant(null, typeof(Dictionary<,>)) and some other expressions (though often other rules will get in the way) are allowed.

Since these represent a value of an open generic type, they aren't really meaningful.

They can have a value of null which can be used as long as it is converted to object and both compilation types accept Expression.Lambda<Func‎<object>>(Expression.Default(typeof(List<>))) as an expression that can be compiled into a delegate that returns null.

While they can be pressed into service, it seems more appropriate to prohibit them.

Factory methods that have at least one overload that takes Type arguments directly. Will check these off when they're either found to already prohibit such types, or fixed to do so (PRs just adding tests of already-correct behaviour marked immediately, PRs fixing behaviour upon acceptance):

Also the following have overrides that take MemberInfo, which could be generic and/or be related to an open generic type. Most will block this with restrictions they place on those MemberInfo arguments relating to other types, but they need to be checked.

@JonHanna
Copy link
Contributor Author

Several of them can also be typed as byref and/or pointer types.

JonHanna referenced this issue in JonHanna/corefx Apr 30, 2016
Move existing default tests from SequenceTests.cs to new file and add more.

Throw on null type in call to Default(). Fixes #8190.

Throw on open generic, byref or pointer type to Default(). Contributes to #8081.

# Conflicts:
#	src/System.Linq.Expressions/tests/System.Linq.Expressions.Tests.csproj
JonHanna referenced this issue in JonHanna/corefx Apr 30, 2016
Move existing default tests from SequenceTests.cs to new file and add more.

Throw on null type in call to Default(). Fixes #8190.

Throw on open generic, byref or pointer type to Default(). Contributes to #8081.
JonHanna referenced this issue in JonHanna/corefx Apr 30, 2016
Throw on open generic, byref or pointer type to NewArrayBounds().

Contributes to #8081.

Also add further tests beyond this.

Note that on byref this already threw TypeLoadException, but ArrayException
would be more consistent.
JonHanna referenced this issue in JonHanna/corefx May 1, 2016
Throw on open generic, byref or pointer type to Constant(). Contributes to #8081.
JonHanna referenced this issue in JonHanna/corefx May 4, 2016
Contributes to #8081.

Also add further tests beyond this.

Note that on byref this already threw TypeLoadException, but
ArgumentException would be more consistent.
JonHanna referenced this issue in JonHanna/corefx May 4, 2016
Contributes to #8081.

Just tests that it isn't accepted along with null constants (typed as
object). Currently it is possible to create a ConditionalExpression
that violates this rule, but it requires an other expression type to
do so, so when the rest of #8081 is dealt with then coerced null would
be the only remaining possibilty that wouldn't have already thrown in
creating a child expression.
JonHanna referenced this issue in JonHanna/corefx Jul 25, 2016
Contributes to #8081.

Only explicit use of the types are corrected here; creating an open generic or
byref jump expression through use of a value of such a type will be prohibited
by the rest of #8081 preventing such values ever existing.
JonHanna referenced this issue in JonHanna/corefx Jul 25, 2016
Contributes to #8081.

Only explicit use of the types are corrected here; creating an open generic or
byref jump expression through use of a value of such a type will be prohibited
by the rest of #8081 preventing such values ever existing.
JonHanna referenced this issue in JonHanna/corefx Jul 25, 2016
Contributes to #8081.

Only explicit use of the types are corrected here; creating an open generic or
byref jump expression through use of a value of such a type will be prohibited
by the rest of #8081 preventing such values ever existing.
JonHanna referenced this issue in JonHanna/corefx Jul 26, 2016
JonHanna referenced this issue in JonHanna/corefx Jul 26, 2016
Also test open generics are prohibited.

Contributes to #8081
@hughbe
Copy link
Contributor

hughbe commented Sep 14, 2016

Should the following be prohibited or allowed (they are currently allowed):

Expression.Variable(typeof(GenericClass<>);
Expression.Parameter(typeof(GenericClass<>);

I'm fairly sure the Variable one is a bug (the C# compiler doesn't allow it), but I'm uncertain about Parameter.

@svick
Copy link
Contributor

svick commented Sep 14, 2016

@hughbe Since Variable() and Parameter() are almost interchangeable, I think they should behave the same here.

And as far as open generic types go, I don't see any reason to allow them.

@hughbe
Copy link
Contributor

hughbe commented Sep 14, 2016

@svick perf, I'll make a PR once dotnet/corefx#11701 is merged

@JonHanna
Copy link
Contributor Author

JonHanna commented Dec 9, 2016

I've just found that TypeAs can be typed as pointer and ref types, so there's at least one case that is still affected by this.

@hughbe
Copy link
Contributor

hughbe commented Dec 9, 2016

Oh whoops I'm not sure I meant to close this issue. Feel free to reopen if u want

@JonHanna
Copy link
Contributor Author

JonHanna commented Dec 9, 2016

I can't due to isaacs/github#583

JonHanna referenced this issue in JonHanna/corefx Dec 9, 2016
Contributes to #8081

Futher test TypeAs validation.
@stephentoub stephentoub reopened this Dec 11, 2016
@JonHanna
Copy link
Contributor Author

I had been working systematically on this, before I wasn't able to contribute much for a while last summer. Need to track what, if anything remains in this, issue. Shall update the opening comment with a task list.

JonHanna referenced this issue in JonHanna/corefx Feb 14, 2017
JonHanna referenced this issue in JonHanna/corefx Feb 14, 2017
JonHanna referenced this issue in JonHanna/corefx Feb 14, 2017
Method which matches the required signature, but is declared on an open
generic type.

Contributes to #8081
JonHanna referenced this issue in JonHanna/corefx Feb 14, 2017
Method which matches the required signature, but is declared on an open
generic type.

Contributes to #8081
JonHanna referenced this issue in JonHanna/corefx Feb 14, 2017
Contributes to #8081, but since the current behaviour is to safely
always return false, continue to allow pointer type operands.

There is already code that examines these expressions for always-false
or always-true behaviour, so have pointer types also result in the
always-false path being taken.
JonHanna referenced this issue in JonHanna/corefx Feb 15, 2017
JonHanna referenced this issue in JonHanna/corefx Feb 16, 2017
Contributes to #8081.

Also fill other testing gaps in MemberExpression.
JonHanna referenced this issue in JonHanna/corefx Feb 16, 2017
JonHanna referenced this issue in JonHanna/corefx Feb 17, 2017
JonHanna referenced this issue in JonHanna/corefx Feb 18, 2017
Contributes to #8081, but since the current behaviour is to safely
always return false, continue to allow pointer type operands.

There is already code that examines these expressions for always-false
or always-true behaviour, so have pointer types also result in the
always-false path being taken.
JonHanna referenced this issue in JonHanna/corefx Feb 21, 2017
Contributes to #8081

Block a case of a method from an open generic type.
JonHanna referenced this issue in JonHanna/corefx Feb 24, 2017
Method which matches the required signature, but is declared on an open generic type.

Contributes to #8081
JonHanna referenced this issue in JonHanna/corefx Mar 2, 2017
JonHanna referenced this issue in JonHanna/corefx Mar 21, 2017
JonHanna referenced this issue in JonHanna/corefx Apr 6, 2017
@JonHanna
Copy link
Contributor Author

Marking MakeIndex and MakeMemberAccess as okay as they make quite simple calls into methods already covered.

JonHanna referenced this issue in JonHanna/corefx Apr 19, 2017
JonHanna referenced this issue in JonHanna/corefx Apr 21, 2017
JonHanna referenced this issue in JonHanna/corefx Apr 24, 2017
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants