Revert "Re-add static interface trimming with more testing (#2791)" #2841
Conversation
…)" This reverts commit ff646e0.
I haven't been able to repro yet. Should we consider making a pipeline for apicompat in this repo to test riskier linker changes? |
|
I think setting up a runtime build in the linker ci is going to be more effort than it's worth - I would rather spend some time figuring out how to run ApiCompat locally - that's something we should be able to do anyway. Once we can do that, let's add test coverage for the new failure, and then I think it's ok to try again. It's not the end of the world if we then have to revert again, but let's at least try to catch problems locally if we can. |
|
I went ahead and hit merge, just to make sure we don't ship the bug in the next preview. |
…otnet#2791)" (dotnet#2841)" This reverts commit 4bed0da.
…otnet#2791)" (dotnet#2841)" This reverts commit 4bed0da.
…otnet#2791)" (dotnet#2841)" This reverts commit 4bed0da.
…nker#2791)" (dotnet/linker#2841) This reverts commit dotnet/linker@ff646e0. Commit migrated from dotnet/linker@4bed0da
This reverts commit ff646e0.
The latest linker update in dotnet/runtime#70614 with the static interface trimming has more failures than the previous and they look similar to the previous failures static interface trimming has caused. I think we should revert static interface trimming in the meantime.