[linker] Remove non-bitcode compatible code, and show a warning. #5551
Conversation
Remove code not currently compatible with bitcode and replace it with an exception instead (otherwise we'll assert at runtime). Also show a warning when we detect this. This is quite helpful when looking at watch device test runs to filter out failures we already know about. This fixes point #2 in dotnet#4763.
|
Build failure Test results1 tests failed, 0 tests skipped, 82 tests passed.Failed tests
|
docs/website/mtouch-errors.md
Outdated
|
|
||
| Currently Xamarin.iOS does not support the 'filter' exception clauses when | ||
| compiling to bitcode. Any methods containing such code will throw a | ||
| NotSupportedException exception. |
There was a problem hiding this comment.
The description is not clear when the exception is thrown.
Is the current behaviour to assert when executing the method ? or
only when an exception occurs ? or
only when an exception with a filter occurs ?
There was a problem hiding this comment.
The current behavior is to throw an exception when the method is executed (LLVM completely fails for the method if it contains a filter clause, which means that there's no native code for the method at all). I've seen asserts too, but I'm not sure when it asserts and when an exception is thrown.
I've updated the text to be more descriptive.
| ```csharp | ||
| void Method () | ||
| { | ||
| throw new NotSupportedException ("This method contains IL not supported when compiled to bitcode."); |
There was a problem hiding this comment.
That example should be copied in the main documentation (or be linked from).
try {
ThrowsAnExceptionOnlyOnTuesday ();
} catch (Exception e) {
throw new NotSupportedException ("This method contains IL not supported when compiled to bitcode.");
}
}
since it's not clear (from the warning) which of the above code is generated as a replacement.
There was a problem hiding this comment.
By "main documentation" you mean mtouch-errors.md?
There was a problem hiding this comment.
yes, that's wait double-clicking on the error/warning will give to developers
|
|
||
| namespace MonoTouch.Tuner { | ||
|
|
||
| public class RemoveBitcodeIncompatibleCodeStep : BaseStep { |
There was a problem hiding this comment.
maybe a SubStep would be better (less code, since it shares the assembly/types/methods iterations) ?
There was a problem hiding this comment.
I've changed it to use a SubStep.
* Add support for reporting more than one MT2105 at the same time when making the errors instead of warnings. * Only report MT2105 for methods that haven't been linked away. * Format the error message nicer for properties.
|
Build failure Test results2 tests failed, 0 tests skipped, 81 tests passed.Failed tests
|
| using Xamarin.Linker; | ||
|
|
||
| namespace MonoTouch.Tuner { | ||
| public class RemoveBitcodeIncompatibleCodeStep : BaseSubStep { |
There was a problem hiding this comment.
oops, I guess I should have fully completed my train of thoughts... :)
ExceptionalSubStep makes support a lot easier if an exception is thrown during processing (which was the main drawback of substeps), otherwise there's no way to know (from logs) what caused the issue
|
Build success |
|
Build failure |
|
Build success |
* [linker] Remove non-bitcode compatible code, and show a warning. Remove code not currently compatible with bitcode and replace it with an exception instead (otherwise we'll assert at runtime). Also show a warning when we detect this. This is quite helpful when looking at watch device test runs to filter out failures we already know about. This fixes point #2 in #4763. * Improve documentation. * Simplify linker code by using a substep. * Fix whitespace issues. * Improve reporting. * Add support for reporting more than one MT2105 at the same time when making the errors instead of warnings. * Only report MT2105 for methods that haven't been linked away. * Format the error message nicer for properties. * Tweak a bit for warning tests to pass. * Use ExceptionalSubStep to provide better error information. * Adjust where linker warnings/errors are reported from to avoid a NullReferenceException.
Remove code not currently compatible with bitcode and replace it with an exception instead (otherwise we may assert at runtime).
Also show a warning when we detect this.
This is quite helpful when looking at watch device test runs to filter out failures we already know about, since this exception message is much more specific than the one mono throws ("Attempting to JIT compile method ...").
This fixes point #2 in #4763.