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

Add support for parsing and working with CustomModifiers in field signatures and make TypeSystemMetadataEmitter more flexible #70593

Merged
merged 2 commits into from
Jun 10, 2022

Conversation

davidwrighton
Copy link
Member

  • 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
@lambdageek
Copy link
Member

/cc @mdh1418

var ilLookupModule = (EcmaModule)lookupContext.GetModuleForSimpleName("Lookup");
FieldDesc fieldFound = ilLookupModule.GetField(token);

Assert.Equal("fieldWithModOpt", fieldFound.Name);
Copy link
Member

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
Copy link
Member

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.

Copy link
Member

@trylek trylek left a 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!

@davidwrighton davidwrighton merged commit 83bd401 into dotnet:main Jun 10, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jul 11, 2022
@davidwrighton davidwrighton deleted the FieldCustomModifierHandling branch April 13, 2023 18:53
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants