Part of 0344842a6b in `xcode10.2` branch
This happens on the latest iOS 12.1.x - but not in the 12.1 simulators
shipped with the current Xcode 10.1 stable release.
However people can hit this error while running tests on (updated)
devices so it's best to include the fix on master.
* [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.
Rework BCL test importation to generate projects that won't compile instead of
giving up completely in case of generation failure.
This means that xharness can still be used for non-BCL tests even if the
generation of the BCL tests fail.
* [tests] Use latest version of NUnit for test projects to get support for parallelized tests.
* [xharness] Automatically find the correct nunit-console executable for NUnit tests.
This is usually not a problem, because these variables are already set when
running from the command-line or xharness. However, it shows up when running
tests directly from VSfM.
Deserialize cached Objective-C class symbols to match how the objects looked
before serialization. This means storing the Objective-C class name in the
Symbol.ObjectiveCName field, and not the Symbol.Name field.
Fixes https://github.com/xamarin/xamarin-macios/issues/5467.
The `[NullAllowed]` attribute should not be allowed on methods but it
could break existing binding projects.
Historically it was used on property setters. However using the attribute
on _other_ methods can be misleading, e.g. should it apply to all
parameters, the return value... and its presence/action can be
misinterpreted in code reviews leading to binding bugs.
reference: https://github.com/xamarin/xamarin-macios/issues/5416
Since we support categories, there is a test that does not longer needs
to be ignored in ios and tvos but needs to be in watchos (we do not yet
have the correct test assembly for the platform).
Since we support filtering there are a number of tests that were ignore
that are part of a ignored category, therefore, they are not needed in
the file.
This can happen if a `[Wrap]` is used on the property getter (and setter)
instead of directly on the property.
In such condition we can safely assume that no dirty check is needed and
can continue with, unmodified, generation (using the wrapped content).
reference: https://github.com/xamarin/xamarin-macios/issues/5444
Rolf Bjarne Kvinge
Alexander Köplinger
Sebastien Pouliot
Curtis Wensley
Marius Ungureanu
Manuel de la Pena
Vincent Dondain