Local function attributes emit#39226
Local function attributes emit#39226RikkiGibson merged 16 commits intodotnet:features/local-function-attributesfrom
Conversation
RikkiGibson
added
the
PR For Personal Review Only
RikkiGibson
force-pushed
the
lfa-attrs-emit
branch
from
b4a8560 to
31b8a27
Compare
RikkiGibson
removed
the
PR For Personal Review Only
|
Could I please get a second sign-off @dotnet/roslyn-compiler #Closed |
|
Ping @dotnet/roslyn-compiler #Closed |
| internal override bool IsExpressionBodied => false; | ||
| internal MethodSymbol TopLevelMethod => _topLevelMethod; | ||
|
|
||
| public override ImmutableArray<CSharpAttributeData> GetAttributes() => _originalMethod.GetAttributes(); |
There was a problem hiding this comment.
Hmm, I wonder if we should just override this for CCI. Maybe this should throw Unreachable? Who is asking for the attributes on a synthesized symbol? #Resolved
There was a problem hiding this comment.
This is used when emitting the synthesized symbol's attributes. #Resolved
|
It doesn't look like we are emitting attributes on type parameters. Also, what about other attributes normally synthesized by the compiler (dynamic, nullable, etc.) Do we emit those? Should we? #Closed |
|
Done with review pass (Iteration 9) #Closed |
…utes' into lfa-attrs-emit
|
I was depending on NamedTypeSymbol implementing INamedTypeSymbol in some of the tests, will fix. #Closed |
|
Could I please get a second review @dotnet/roslyn-compiler #Closed |
|
I'm still not clear on why we're overriding GetAttributes, which I view as a binding-level method, for retrieving attributes on synthesized symbols, instead of either IReference.GetAttributes(EmitContext) or GetAttributesToEmit. I feel like any point where we are actually calling GetAttributes on a synthesized symbol is probably a bug, and if it wants to know the emit attributes it should call GetAttributesToEmit. #Resolved |
I am not sure why you would view things this way. The |
|
Talked with @AlekseyTs offline. The invariant that I thought should hold doesn't really hold. In that case, GetAttributes seems like the right thing to use. #Resolved |
| /// <summary> | ||
| /// Indicates whether synthesized methods derived from this method should inherit the attributes of this method, its parameters, return type, and type parameters. | ||
| /// </summary> | ||
| internal virtual bool SynthesizedMethodsInheritAttributes => false; |
There was a problem hiding this comment.
internal virtual bool SynthesizedMethodsInheritAttributes => false; [](start = 8, length = 67)
I find this approach very fragile and error prone. There could be multiple synthesized methods of different nature associated with the same "base" method. The property whether attributes should be inherited belongs to the specific synthesized method instead. Please make the change. #Closed
|
Follow up to #39226 (comment)
It looks like there is still a gap for emitting the attributes of type parameters. Will make sure to address this in follow-up. #Resolved |
| comp.VerifyDiagnostics(); | ||
| var verifier = CompileAndVerify(comp); | ||
|
|
||
| // PROTOTYPE: EnumeratorCancellation attribute should produce a combinedTokens field and modify codegen |
There was a problem hiding this comment.
PROTOTYPE [](start = 15, length = 9)
We usually add feature name after the "PROTOTYPE" word in parens. I.e. PROTOTYPE(<feature name here>). #Closed
| return builder.ToImmutableAndFree(); | ||
| } | ||
|
|
||
| public override ImmutableArray<CSharpAttributeData> GetAttributes() |
There was a problem hiding this comment.
override [](start = 15, length = 8)
sealed? #Closed
| : ImmutableArray<CSharpAttributeData>.Empty; | ||
| } | ||
|
|
||
| public override ImmutableArray<CSharpAttributeData> GetReturnTypeAttributes() |
There was a problem hiding this comment.
override [](start = 15, length = 8)
sealed? #Closed
|
|
||
| var localFn4 = cClass.GetMethod("<M>g__local4|0_3"); | ||
| var attrs4 = localFn4.TypeParameters.Single().GetAttributes(); | ||
| Assert.Equal("A", attrs4.Single().AttributeClass.Name); |
There was a problem hiding this comment.
attrs4.Single() [](start = 34, length = 15)
I don't see any change that would enable inheritance of attributes for type parameters. It looks like this is done unconditionally and unintentionally (we do want this for local functions, but not for any other case). #Closed
| [Theory] | ||
| [MemberData(nameof(OptimizationLevelTheoryData))] | ||
| [WorkItem(431, "https://github.com/dotnet/roslyn/issues/431")] | ||
| public void BaseMethodWrapper_DoNotInheritAttributes(OptimizationLevel optimizationLevel) |
There was a problem hiding this comment.
BaseMethodWrapper_DoNotInheritAttributes [](start = 20, length = 40)
Please include coverage for attributes on type parameters as well. #Closed
|
Done with review pass (iteration 16) |
6 participants
Related to #38801
This PR includes emitting the attributes in metadata, but not compiler recognition of most well-known attributes for local functions in source.