You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We disallow restricted types in expression trees (since #30871). But we exclude conversions to restricted types - #30871 (comment) mentions avoiding duplicate diagnostics, but there are other scenarios which result in no diagnostics at all, like:
using System;using System.Linq.Expressions;
C.R(()=> C.M(newstring[]{"a"}));staticclassC{publicstaticvoidR(Expression<Action>e)=> e.Compile()();publicstaticvoidM(ReadOnlySpan<string>x)=> Console.Write(x[0]);}
I'm still a bit surprised that this runs at all. Part of the reason that we banned ref struct in expression trees is because, at the time at least, they would not actually be able to compile and execute. It seems like at least in some cases there is no issue executing the code.
@VSadov, @agocke can you all help clarify when an expression tree can and cannot call a method that has a ref struct parameter?
I think most expression trees would compile and run fine. A problematic one was for example with default(RefStruct) constant because that would be passed into Expression.Constant as an object parameter and hence boxed - as explained in #30776 (comment).
Bringing up part of the conversation from that issue
However the Expression.Constant(object, Type) requires the default(Struct1) to be boxed into object, which ref structs don't support.
In this case though default isn't a constant, it's a value. Is it just a terminology issue and we typically represent using the Expression.Constant API?
@RikkiGibson as he wrote the statement I'm questioniing 😄
I think most expression trees would compile and run fine.
I'm not sure about most. I think the problematic cases are where ref structs are used as literals (the constant case) or captured. My recollection here was rather than try to enumerate all the problematic cases, we just banned them entirely.
We disallow restricted types in expression trees (since #30871). But we exclude conversions to restricted types - #30871 (comment) mentions avoiding duplicate diagnostics, but there are other scenarios which result in no diagnostics at all, like:
SharpLab
Note that this currently compiles and runs, so fixing this bug would be a breaking change.
The text was updated successfully, but these errors were encountered: