[release/5.0] Mark generic arguments of dynamically accessed types passed as string #1635
Conversation
* Add type parser * PR feedback * Fix mono build * Move corert code to external * Match filepaths
…et#1546) We always assumed that the generic parameters would come from the same assembly as the generic type itself. Adds a new test to validate the scenario.
…n instruction if its MarkStep's ProcessReflectionDependency() returns true.
…dotnet#1566) * Mark dynamically accessed generic arguments * Clean test * Use MarkType for keeping generic args Enable ComplexTypeHandling tests * Use MarkTypeVisibleToReflection for generic arguments Clean tests * MarkType always * Check for array types in TypeNameResolver * Mark System.Array instead of its element type * Whitespace * PR feedback * Pattern match Whitespace * Add extension method ResolveToMainTypeDefinition * Add comment * Use ResolveToMainTypeDefinition
mateoatr
requested review from
marek-safar,
vitek-karas,
MichalStrehovsky and
agocke
|
I'm a bit nervous to include the new type name parser in a servicing fix. Would you have some estimate how much of the fix would "not work" if we stick to the old ways of handling "type name" -> "type def"? |
|
I think we'd be good for the most part, I did some testing with the example provided in #1559 and it seems to work fine. I have a branch with the fix using the old type name parser: release/5.0...mateoatr:markGenArgs |
|
I actually like that fix way better for servicing. One comment: release/5.0...mateoatr:markGenArgs#diff-565c4d3a1fda40fe49e36a001479e217a6a484722f6e97ee132c3ddcefdbd585R1572-R1573 the |
|
Agreed. Closing this PR in favor of #1637. |
Backport of #1566. Since 1566 makes use of
TypeNameResolver, I had to cherry pick other commits as well:Allow ReflectionMethodBodyScanner's HandleCall() to skip processing an instruction if its MarkStep's ProcessReflectionDependency() returns true. (#1548)
Correctly handle assembly qualified names in generic parameters (#1546)
Port .NET Native type name parser (#1472)