Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
The calli instruction calls a function pointer on the stack, not a specific
managed function, so don't include it when looking for calls to managed functions.
The original implementation for the MidiCIDeviceIdentification struct uses
public byte[] fields with a MarshalAs attribute to set the array size. This is
not blittable, but unfortunately these are _public_ fields, which means we
can't change them.
Instead introduce an internal intermediate struct, which is blittable, and
convert to and from this struct when marshalling to and from native code.
Then in XAMCORE_5_0 we can make the intermediate struct public and use it
instead of the non-blittable struct everywhere.
This fixes a test failure when not including all platforms:
Cecil.Tests.BlittablePInvokes.CheckForNonBlittablePInvokes: Known failures that aren't failing anymore - remove these from the list of known failures: In the file tests/cecil-tests/BlittablePInvokes.cs, read the guide carefully.
Expected: <empty>
But was: < "AudioUnit.AudioComponentStatus AudioUnit.AudioUnit::AudioOutputUnitPublish(AudioUnit.AudioComponentDescription,System.IntPtr,System.UInt32,System.IntPtr)", ...
We have some code that verifies a list of failures against a known set of
failures and:
* Fails if any known failure is fixed.
* Fails if there any new (unknown) failures.
Create a helper method that contains this logic, since it's duplicated quite a
few times across various tests.
Removed a flavor of `class_addMethod` that is unused.
Ignored a few cases that are going to be in .NET and/or may break AOT
optimizations
Now all iOS pivots pass, 17 macOS remain.
Updates the pinvokes in CoreFoundation to have blittable types.
I intentionally did *not* do `CFReadStream` and `CFWriteStream` as the
changes needed for those are may create a breaking API change, so those
should probably be their own PR for closer scrutiny.
Please look closely at CFProxySupport as that was the least
straightforward of the changes.
* Add obsolete attributes for all platforms.
* Make sure the same obsolete message is used on all platforms.
* Fix a few typos.
There are many more APIs to fix (as evidenced by the fact that this only
removes a few known failures), but this is how far I've gotten right now.
Also fix a few issues:
* Fix an issue with replicating availability attributes with a third digit.
The third version number is 'Build', not 'Revision' (which is fourth), so
adjust our code accordingly.
This fixes an issue where the copy of 'macos10.15.4' would become
'macos10.15' and we'd lose the third number.
* Fix an issue when generating filter code. We were using the wrong type as
the target (inlined) type, resulting in the wrong availability attributes
getting created sometimes.
Stop implying Mac Catalyst attributes from the iOS attributes, and instead
treat Mac Catalyst like all the other platforms (not implying anything from
any other platform).
This makes our attribute logic much easier to reason about and understand.
It also required adding numerous Mac Catalyst attributes that were previously
implied. This task was way too big to do manually, so I made some changes to
Chris' mellite tool, and managed to do it quite easily with Roslyn with the
changes in this branch: https://github.com/rolfbjarne/mellite/tree/explicit-maccatalyst-attributes
Protocols with one set of introduced attributes ([TV (12, 0)]) inlined in
types that were introduced in a different version ([TV (10, 0)]) would always
use the attributes from the type.
This is wrong if the protocol was introduced after the type, in which case we
should instead use the introduced attributes from the protocol.
Fix this by choosing the latest introduced attribute when we have multiple to
choose from.
This required passing a bit more information around so that we always know if
a member is being inlined in another type.
This PR will also print availability attributes on the protocol members themselves:
[Protocol]
interface IProtocol
{
[TV (12, 0)] // this was not printed before
[Export ("someProperty")]
string SomeProperty { get; set; }
}
Also add and improve some tests.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/14802.
* Fix an issue where it would not compute the correct grouping key for each member,
effectively grouping unrelated members together and coming up with weird and incorrect
results.
* Make it match failures exactly, which makes it possible to detect (and report,
which it now does) when a known failure is fixed.
* Ignore any hidden members (EditorBrowsableState.Never), because they're most
likely mistakes.
* Ignore any members in AppKit and UIKit, because these namespaces have a lot of
conflicting availability attributes. This is tracked in a separate bug (#17292).
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This PR handles two scenarios (fixed in separate commits):
Scenario 1:
* The property has different availability attributes than the containing type.
* The property's accessor(s) do not have availability attributes.
We'd generate the wrong availability attributes for the property accessors,
because we'd take the type's availability attributes and add them to the
accessors.
As for the fix: I can't really explain it. This code is rather impenetrable,
and the parameter names don't make much sense, but whatever I did seems to
work?
And it turns out this fix shows up in an existing test as well (the
generator's Bug35176 test), which I had to modify to remove the expectation of
(now redundant) availability attributes that we no longer produce.
Scenario 2:
* Type is available on iOS, tvOS.
* Property in the type is available on iOS (and not tvOS).
* Property accessor has explicit availability attributes for iOS.
Then the property accessor would get the availability attribute for tvOS from
the type, and not the (un)availability attribute from the property.
The fix is to make sure the parent context is the property (and not the type)
when processing availability attributes for the accessor.
According to the compilation compilation directives, these APIs are not
available on tvOS nor macOS, so update the availability attributes
accordingly.
Rolf Bjarne Kvinge
Git History Editor
Alex Soto
Steve Hawley