Skip to content

Correctness fixes to interface stripping #1305

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

Merged
merged 3 commits into from
Jul 3, 2020

Conversation

MichalStrehovsky
Copy link
Member

This is actually 3 separate things:

  • Bugfix in linker where linker was stripping type Foo despite the program containing a new Foo[x,y] statement. I hit this while writing tests for this.
  • If a type is used as an array element or as a generic argument, don't strip any of its interfaces because they might be necessary for variant casting later.
  • If a type is visible from reflection, don't strip any of its interfaces.

Fixes #1235.

This is actually 3 separate things:

* Bugfix in linker where linker was stripping type `Foo` despite the program containing a `new Foo[x,y]` statement.
* If a type is used as an array element or as a generic argument, don't strip any of its interfaces because they might be necessary for variant casting later.
* If a type is visible from reflection, don't strip any of its interfaces.

Fixes dotnet#1235.
@@ -2652,6 +2670,9 @@ protected virtual void MarkInstruction (Instruction instruction, MethodDefinitio
}

case OperandType.InlineType:
if (instruction.OpCode.Code == Code.Newarr) {
Annotations.MarkRelevantToVariantCasting (((TypeReference) instruction.Operand).Resolve ());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolve may return null - in which case we will add null to the HashSet in Annotations. I guess it doesn't matter that much, but it might be cleaner to check for null in the MarkRelevantToVariantCasting before adding it to the hashset.

@@ -2652,6 +2671,9 @@ protected virtual void MarkInstruction (Instruction instruction, MethodDefinitio
}

case OperandType.InlineType:
if (instruction.OpCode.Code == Code.Newarr) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure this is the only relevant opcode? What about code like var foos = (IFoo[]) Array.CreateInstance (typeof (Foo), 1); ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That pattern should be fine because the typeof(Foo) means "visible to reflection" and that's handled elsewhere in this pull request.

@MichalStrehovsky MichalStrehovsky merged commit c66de69 into dotnet:master Jul 3, 2020
@MichalStrehovsky MichalStrehovsky deleted the stripping branch July 3, 2020 11:43
mrvoorhe added a commit to Unity-Technologies/linker that referenced this pull request Nov 18, 2020
mrvoorhe added a commit to Unity-Technologies/linker that referenced this pull request Nov 18, 2020
tkapin pushed a commit to tkapin/runtime that referenced this pull request Jan 31, 2023
This is actually 3 separate things:

* Bugfix in linker where linker was stripping type `Foo` despite the program containing a `new Foo[x,y]` statement.
* If a type is used as an array element or as a generic argument, don't strip any of its interfaces because they might be necessary for variant casting later.
* If a type is visible from reflection, don't strip any of its interfaces.

Fixes dotnet/linker#1235.

Commit migrated from dotnet/linker@c66de69
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Interface stripping produces invalid outputs
3 participants