-
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
Add support for parsing and working with CustomModifiers in field signatures and make TypeSystemMetadataEmitter more flexible #70593
Add support for parsing and working with CustomModifiers in field signatures and make TypeSystemMetadataEmitter more flexible #70593
Conversation
davidwrighton
commented
Jun 10, 2022
- Update TypeSystemMetadataEmitter to be able to generate a field signature given an appropriate array of EmbeddedSignatureData[]
- Add api to FieldDesc to allow the custom modifier data to be handled using the same scheme as custom modifier data on method signatures
- Adjust TypeSystemMetadataEmitter to be able to generate metadata not just for the Mibc emitter
- The current implementation has some default behavior around creating metadata that is in the constructor. Break that out into helper functions so that other scenarios don't need to run that code.
- Add an entrypoint for generating metadata for an arbitrary TypeSystemEntity
- Add a feature to allow it the ResolutionScope of a non-nested type to be managed specially. This will be needed by Add support for cross module inlining and cross module generic compilation to Crossgen2 #68919
…natures and make TypeSystemMetadataEmitter more flexible - Update TypeSystemMetadataEmitter to be able to generate a field signature given an appropriate array of EmbeddedSignatureData[] - Add api to FieldDesc to allow the custom modifier data to be handled using the same scheme as custom modifier data on method signatures - Adjust TypeSystemMetadataEmitter to be able to generate metadata not just for the Mibc emitter - The current implementation has some default behavior around creating metadata that is in the constructor. Break that out into helper functions so that other scenarios don't need to run that code. - Add an entrypoint for generating metadata for an arbitrary TypeSystemEntity - Add a feature to allow it the ResolutionScope of a non-nested type to be managed specially. This will be needed by dotnet#68919
/cc @mdh1418 |
var ilLookupModule = (EcmaModule)lookupContext.GetModuleForSimpleName("Lookup"); | ||
FieldDesc fieldFound = ilLookupModule.GetField(token); | ||
|
||
Assert.Equal("fieldWithModOpt", fieldFound.Name); |
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.
Should we also check the modopt on the field?
@@ -45,6 +45,9 @@ public virtual string Name | |||
get; | |||
} | |||
|
|||
// Get the embedded signature data used to hold custommodifiers and such within a field signature |
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.
Nit / typo - it seems to me it would be a tad more readable if we used a blank to turn these into normal words custom modifiers, after all it's not a direct reference to a type name or some such.
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.
Looks great to me, thank you!