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.
I started fixing nullability in one place, and then it snowballed a bit
and I had to fix nullability in a lot of places.
Most are trivial, except for the `generate-frameworks-constants`
project: I had to create a .NET version of the project in order to
compile a .NET version of the tool.
Also fix a nullability warning.
Fixes these warnings:
"tests/generator/generator-tests.csproj" (default target) (1:7) ->
(CoreCompile target) ->
tests/generator/AttributeFactoryTests.cs(43,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(44,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(45,29): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(17,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(34,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(53,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(54,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(55,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(56,39): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(64,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(69,11): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(76,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(55,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(83,34): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(78,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(111,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(138,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(95,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/AttributeFactoryTests.cs(178,16): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.
tests/generator/ConstructorArgumentsTests.cs(116,19): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(194,18): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(210,18): warning CS0436: The type 'AttributeFactory' in 'tests/generator/../../src/bgen/AttributeFactory.cs' conflicts with the imported type 'AttributeFactory' in 'bgen, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'tests/generator/../../src/bgen/AttributeFactory.cs'.]
tests/generator/ConstructorArgumentsTests.cs(197,44): warning CS8602: Dereference of a possibly null reference.
tests/generator/ConstructorArgumentsTests.cs(201,43): warning CS8602: Dereference of a possibly null reference.
Some changes:
1. Move all the static attr related methods to the attr factory.
2. Make it simpler to see the diff between NET and not by using a
partial class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This will be required when we make blocks use blittable callbacks, since we'll
have to use pointers in a few cases (because ref/out arguments aren't
blittable).
Naming could be problematic when generating code, move the logic out of
the generator class to a helper class whose only job is to name classes
and keep track of names.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Several changes:
- Refactored AsyncMethodInfo and move the collection extensions out of
the Generator class.
- Added tests for the collection extension methods.
- Fix a mistake/bug in which Last was used instead of LastOrDefault
(funny comment was close to the right reason).
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Move all the string methods that can be an extension to a static class
(re-use the present one) and add tests.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Moved the extension methods to their own file and enabled nullable.
Fixed the following underlying bug:
The extension method that creates a valid parameter named does not do
the right thing in the following cases:
1. When the starting illegal char is NOT a number. It will prepend @
fixing nothing. Example " OHOH" to "@ OHOH"
2. When the illegal chars is in the middle of the param name. Example
"OH OH" to "@OH OH"
I have fixed the method to return null in those ocassions (we will need
to enable nullability later in the generator, is too much for this PR).
Tests have been added to ensure we do not have such an issue again.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
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
This is the first part of a 2 or more changes that will allow the APIs
to use ? as a way to mark a nullable field, parameter, property and
return method.
The way it works follows the documentation from the runtime that can be
found here:
https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
The tldr; of the documentation is as follows:
1. If we are looking at a value type, the compiler converts int? into
Nullable<int>. This was already considered in the old code.
2. If we are inspecting a generic type we have to look for the
information in two different attributes added by the compiler: -
NullableAttribute: Each type reference in metadata may have an
associated NullableAttribute with a byte[] where each byte represents
nullability: 0 for oblivious, 1 for not annotated, and 2 for annotated.
- NullableContextAttribute is valid in metadata on type and method
declarations. The byte value represents the implicit NullableAttribute
value for type reference within that scope that do not have an explicit
NullableAttribute and would not otherwise be represented by an empty
byte[].
The API is very similar to that provided by dotnet6 but it allows us to
support classic. The move to the dotnet6 API should not be hard and
probably can be done by an IDE.
Once this API lands we will have to find the old usages of the check for
nullability and combine both. This new API should fix several issues we
have with nullability and nullability + generics.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
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.
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.
In the following scenario:
* Type T is not available on a platform (say tvOS).
* Protocol P is available on said platform.
* A member M of P has its own availability attribute for said platform (for
instance if P is available on tvOS 11.0, and the member is available on tvOS
12.0).
* The protocol P is inlined into the type T.
We'd include the SupportedOSPlatform attribute from the inlined member on
generated code on other platforms (so the iOS assembly would say that the
inlined member M in T is available on tvOS).
Fixes https://github.com/xamarin/xamarin-macios/issues/17268.
Previously API definitions like this:
string Property {
get;
[NoiOS]
set;
}
would generate a setter for every platform, even iOS.
This is rather unexpected, so fix the generator to honor No* attributes on
property getters and setters.
This hasn't been a problem until now because we've always had tvOS attributes on
most API, but when bumping min OS versions for .NET 8, we'll also remove a lot of
redundant availability attributes. This would break a case where a type is unavailable
on all platforms except tvOS (but without any tvOS availability attribute), and then
we'd get the (implied) iOS (un)availability attribute.
Tests work because other tests do use the nugets and gets picked up by
the runner. Yet, if we execute this projects witjout others, the tests
will fail when trying to use the nunit2 format.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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>
Fixes this NUnit warning:
> labels=All is deprecated and will be removed in a future release. Please use labels=Before instead.
We don't follow the suggestion from the warning, because the advantage of
writing the label after each test is that the test result will also be
printed, which means it's possible to see if any tests failed during the test
run, as opposed to having to wait until the entire test run is completed
(which can take a while) to realize that pretty much every test failed with
some silly mistake which could have been quickly fixed before re-running the
tests.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
This makes us render this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, nint column);
instead of this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, IntPtr column);
Fixes https://github.com/xamarin/xamarin-macios/issues/14107.
We have a problem that's shown up a few times, where we're given an instance
of a native type, where the closest bound managed type is a type declared as
[Abstract] in the api definition. In this case, we want to create an instance
of the [Abstract] type to wrap the native instance, but that hasn't been
possible because the managed type is abstract.
Note: this is totally fine from the OS perspective: it might have created an
instance of a private subclass we haven't bound (or it might even be a public
subclass we just haven't bound yet).
The fix is to:
* Stop making [Abstract] classes in the api definition abstract classes in the generated code.
* Make the default constructor default to "protected" visibility for [Abstract] classes.
This way we can still create instances of these types at runtime when we need
them, but they must be subclassed in order to create a managed instance of
them.
Additionally I also had to make abstract members virtual for such types
(because otherwise the type would have to be abstract as well), and instead
throw a "You_Should_Not_Call_base_In_This_MethodException" in the
corresponding method implementations.
Fixes https://github.com/xamarin/xamarin-macios/issues/4969.
AutoGeneratedName was a toggle to implement a certain (correct) behavior,
while at the same time not cause breaking changes.
Now that we can do breaking changes in .NET, we can remove the toggle (i.e.
the property), and just always do the right thing (that is: automatically
generate a _unique_ Objective-C name for Model classes, unless a name is
specified manually).
Ref: https://github.com/xamarin/xamarin-macios/issues/5107
Manuel de la Pena
Rolf Bjarne Kvinge
Chris Hamons
Alex Soto