-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
ILLink: Remove ScopeStack from MarkStep #102282
Conversation
This reverts commit 3557326.
if (origin.Provider != ScopeStack.CurrentScope.Origin.Provider) { | ||
Debug.Assert (dependencyKind == DependencyKind.DynamicallyAccessedMemberOnType || | ||
(origin.Provider is MethodDefinition originMethod && CompilerGeneratedState.IsNestedFunctionOrStateMachineMember (originMethod))); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion was to make sure that we always passed ScopeStack.CurrentScope.Origin unless the call to MarkField originated from the ReflectionMarker. It always used the parameter origin
, so the behavior is the same and this check isn't necessary.
// There are only two ways to get there such that the origin isn't the same as the top of the scopestack. | ||
// - For DAM on type, the current scope is the caller of GetType, while the origin is the type itself. | ||
// - For warnings produced inside compiler-generated code, the current scope is the user code that | ||
// owns the compiler-generated code, while the origin is the compiler-generated code. | ||
// In either case any warnings produced here should use the origin instead of the scopestack. | ||
if (origin.Provider != ScopeStack.CurrentScope.Origin.Provider) { | ||
Debug.Assert (dependencyKind == DependencyKind.DynamicallyAccessedMemberOnType || | ||
(origin.Provider is MethodDefinition originMethod && CompilerGeneratedState.IsNestedFunctionOrStateMachineMember (originMethod))); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is similar to above with ProcessAnalysisAnnotationsForField. Since we no longer use ScopeStack, this can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks a lot!
Thanks a lot - I always hated this part of the mark step, but was never brave enough to tackle it :-). I remember that when I introduced this even then we didn't like it very much, but it worked... sooo. |
Removes the ScopeStack from the MarkStep to make the MessageOrigin flow clearly traceable. This should be very helpful as we transition to the dependency analysis framework. The changes were fairly mechanical, each place that pushed a scope onto the stack, a new MessageOrigin was created, and all places that used ScopeStack.CurrentScope added a new origin parameter, and the parameter bubbled up to the ProcessX methods. Passing MessageOrigin by value was slightly faster than as an in parameter (and overall this is slightly faster than main), so I made MessageOrigin.ILOffset a non-nullable int to make the struct a bit smaller. I ran the aspnetcore benchmarks trim step and didn't run into issues, so the stack should be large enough to handle it.
Removes the
ScopeStack
from theMarkStep
to make theMessageOrigin
flow clearly traceable. This should be very helpful as we transition to the dependency analysis framework.The changes were fairly mechanical, each place that pushed a scope onto the stack, a new
MessageOrigin
was created, and all places that usedScopeStack.CurrentScope
added a neworigin
parameter, and the parameter bubbled up to theProcessX
methods.Passing
MessageOrigin
by value was slightly faster than as anin
parameter (and overall this is slightly faster than main), so I madeMessageOrigin.ILOffset
a non-nullableint
to make the struct a bit smaller. I ran the aspnetcore benchmarks trim step and didn't run into issues, so the stack should be large enough to handle it.