1dcefc9c56
This PR teaches our code generator to generate .NET 6 style availability attributes, adds a 4th Cecil test to verify our generated attributes, and a metric ton of API changes to satisfy that test.
The generator work is the core of this PR, and includes:
- Hacking out chunks of generator.cs that "helpfully" remove duplicate attributes, which are no longer duplicate in the new order that NET6 attributes force upon us. See changes in FilterMinimumVersion and PrintPlatformAttributes
- Prevent a crash when the generator processes availability attributes with no version included (example: introduced on iOS but no version). See Is64BitiOSOnly.
- The meat, GetPlatformAttributesToPrint, which synthesizes many attributes "out of thing air" from:
- The parent context
- Implied introduced just because the class exists on a given framework at all
- Implied Catalyst because iOS exists
- A few cludgy hacks PrintPlatformAttributesNoDuplicates and GenerateProperty because the existing PrintPlatformAttributes did not pass down parent context down, and the refactor was dangerous/too time consuming given time pressure.
There are two intended API changes introduced by the reviews in this PR:
- GetCurrentInputDevice was obviously intended by availability attributes to exist on Catalyst but due to define confusion was excluded. It is an addition in Microsoft.MacCatalyst.dll only.
- The NEAppRule constructors were mis-marked on platforms, and were showing up incorrectly on Mac/Catalyst. I corrected the Catalyst one unconditionally, as we have not shipped Catalyst yet, but Mac is only fixed in NET6.
There is a lot of follow up work in https://github.com/xamarin/xamarin-macios/issues/14802 to do to remove a number of hard coded test failures, but this should be almost all of the remaining work in NET6 attributes.
🤞 this doesn't break too much for future us.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
|
||
|---|---|---|
| .. | ||
| Mac | ||
| dotnet | ||
| iOS | ||
| ApiAvailabilityTest.cs | ||
| ApiBaseTest.cs | ||
| ApiCMAttachmentTest.cs | ||
| ApiClassPtrTest.cs | ||
| ApiCoreImageFiltersTest.cs | ||
| ApiCtorInitTest.cs | ||
| ApiFieldTest.cs | ||
| ApiFrameworkTest.cs | ||
| ApiPInvokeTest.cs | ||
| ApiProtocolTest.cs | ||
| ApiSelectorTest.cs | ||
| ApiSignatureTest.cs | ||
| ApiStructTest.cs | ||
| ApiTypeTest.cs | ||
| ApiTypoTest.cs | ||
| ApiWeakPropertyTest.cs | ||
| CoreSelectorTest.cs | ||
| EnvironmentVariable.cs | ||
| README.md | ||
| xamarin1.png | ||
README.md
Introspection Tests
Introspection tests are executed on target (both simulator and device for iOS) or a specific version of OSX. The application proceed to analyze itself using:
System.Reflectionfor managed code; and- the ObjectiveC runtime library for native code
and compare the results. E.g. if using .NET reflection it can see a binding
for a NSBundle type then it should be able to find a native NSBundle
type using the ObjC runtime functions. Otherwise an error is raised...
Since the application analyze itself it must contains everything we wish to test. That's why the introspection tests needs to be built with the managed linker disable, i.e. "Don't link".
Pros
- The tests always tell the truth, which can differ from documentation or header files;
Cons
- Incomplete - Not everything is encoded in the metadata / executable;
- Too complete - Not every truth is good to be known (or published), which requires creating special cases in the tests