Parsing assembly qualified type name fails #84118
Labels
Milestone
Comments
dotnet-issue-labeler
bot
added
the
needs-area-label
rolfbjarne
added a commit
to xamarin/xamarin-macios
that referenced
this issue
Mar 30, 2023
|
Tagging subscribers to this area: @dotnet/area-system-reflection Issue DetailsDescriptionParsing the type name Reproduction StepsTest code: var t = Type.GetType ("System.Int32, , System.Private.CoreLib.dll");
Console.WriteLine (t);Expected behaviorThis should be printed: Actual behaviorAn exception: Regression?Yes, the code works fine in .NET 7. Known WorkaroundsNo response ConfigurationOther informationIt happened somewhere in this range: edb161a...8d5f520 I'm guessing this is the culprit: #83484 CC @jkotas
|
marek-safar
removed
the
needs-area-label
We're sure? Based purely on history I would have guessed I might have broken it a few months ago in https://github.com/dotnet/runtime/pull/79048/files#diff-6552989a804d7e6b6e1f065a88d8c17221ea6c6ad561d66348d2f85668f6261f. |
It started breaking in this maestro bump: xamarin/xamarin-macios#17888 |
Yes, the behavior regressed with this change. I am working on a fix. The expected behavior is not correct. |
jkotas
added a commit
to jkotas/runtime
that referenced
this issue
Mar 30, 2023
…assembly name Fixes dotnet#84118
ghost
added
the
in-pr
ghost
removed
the
in-pr
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Apr 10, 2023
… that showed up in code.
There's a 'link all' test that's verifying that the IntroducedAttribute is
linked away. It does so by verifying that the linked app doesn't have a
'IntroducedAttribute' type - but the test was constructing the fully qualified
type name to look for incorrectly:
ObjCRuntime.IntroducedAttribute, , Microsoft.iOS
Note the double comma: that meant we wouldn't find the type, even if it wasn't linked away.
The fix is easy (use a single comma), with one caveat (don't use a constant
string, because the linker sees the reference to
"ObjCRuntime.IntroducedAttribute" and _helpfully_ preserves it, exactly what
we don't want), but it revealed that the tested behavior regressed: a fully
linked app wouldn't link away the IntroducedAttribute.
So a fix is also needed: properly remove TVAttribute, WatchAttribute and
MacCatalystAttribute, which are subclasses of IntroducedAttribute (and what
would make the linker keep IntroducedAttribute).
Interestingly this showed up because of a bug in the runtime, where parsing
the invalid assembly name would now throw an exception
(dotnet/runtime#84118).
rolfbjarne
added a commit
to xamarin/xamarin-macios
that referenced
this issue
Apr 11, 2023
… that showed up in code. (#18016) There's a 'link all' test that's verifying that the IntroducedAttribute is linked away. It does so by verifying that the linked app doesn't have a 'IntroducedAttribute' type - but the test was constructing the fully qualified type name to look for incorrectly: ObjCRuntime.IntroducedAttribute, , Microsoft.iOS Note the double comma: that meant we wouldn't find the type, even if it wasn't linked away. The fix is easy (use a single comma), with one caveat (don't use a constant string, because the linker sees the reference to "ObjCRuntime.IntroducedAttribute" and _helpfully_ preserves it, exactly what we don't want), but it revealed that the tested behavior regressed: a fully linked app wouldn't link away the IntroducedAttribute. So a fix is also needed: properly remove TVAttribute, WatchAttribute and MacCatalystAttribute, which are subclasses of IntroducedAttribute (and what would make the linker keep IntroducedAttribute). Interestingly this showed up because of a bug in the runtime, where parsing the invalid assembly name would now throw an exception (dotnet/runtime#84118).
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Parsing the type name
"System.Int32, , System.Private.CoreLib.dll"fails in the latest .NET 8 builds.Reproduction Steps
Test code:
Expected behavior
This should be printed:
Actual behavior
An exception:
Regression?
Yes, the code works fine in .NET 7.
Known Workarounds
No response
Configuration
Other information
It happened somewhere in this range: edb161a...8d5f520
I'm guessing this is the culprit: #83484
CC @jkotas
The text was updated successfully, but these errors were encountered: