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.
The small typo made the test projects from mac and ios/tvos/watchos be
in different nodes in the xhanress web page which is ugly. They now wil
appear in the same node.
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
All the failing tests have been ignored. There are a large number of
tests ignored on the watchOS platform beacuase atm the iOS test dll is
used.
Fixes https://github.com/xamarin/maccore/issues/1135
There are a number of tests that use a TestFixtureSetup method that
fails. While the xml results report these errors, if a user runs xharness locally,
he will not get the errors reported. This issue meant that we had
different errors reported in jenkis and locally.
* [CoreFoundation, ObjCRuntime] Add DispatchBlock APIs, in particular those that surface QOS
* Make the struct readonly
Co-Authored-By: migueldeicaza <miguel@gnome.org>
* Make the field read-only
Co-Authored-By: migueldeicaza <miguel@gnome.org>
* Add Qos to the list of accepted words
* To add a finalizer that can dispose the object, turn this into a class,
rather than being just a wrapper around the native handle.
* Fix copyright.
* Fix whitespace issues.
* Adjust visibility of existing DispatchBlock method we don't want to make public
* Refactor a bit.
* Make DispatchObject inherit from NativeObject to avoid some code duplication.
* Put all P/Invokes in BlockLiteral.
* Simplify block code somewhat.
* Sprinkle [BindingImpl (Optimizable)] where needed.
* Add both constructors and static Create methods to create DispatchBlocks.
* Add an explicit operator to get an Action delegate from a DispatchBlock, and
an Invoke method to directly call said delegate.
* Add a few convenience API:
* Wait with a TimeSpan overload.
* Cancelled property.
* Notify with an Action overload.
* Add some DispatchQueue overloads to make DispatchBlock actually usable.
* Seal DispatchBlock.
Users shouldn't subclass DispatchBlock.
* Add tests.
* DispatchBlockFlags is native-sized (nuint).
* Fix a few more nint issues.
* Add availability attributes.
* Fix introspection tests.
* Fix xtro.
* Fix xammac tests.
Otherwise we can end up without argument checks and de-reference null
arguments to get the `Handle` property.
Example from #5403 binding original issue:
```diff
diff --git a/src/appkit.cs b/src/appkit.cs
index daf22b75..48390cb8 100644
--- a/src/appkit.cs
+++ b/src/appkit.cs
@@ -431,6 +431,7 @@ namespace AppKit {
interface NSAppearanceCustomization {
[Mac (10,9)]
+ [NullAllowed]
[Export ("appearance", ArgumentSemantic.Strong)]
NSAppearance Appearance { get; set; }
```
would generate
```csharp
[BindingImpl (BindingImplOptions.GeneratedCode | BindingImplOptions.Optimizable)]
public static void SetAppearance (this INSAppearanceCustomization This, NSAppearance value)
{
global::AppKit.NSApplication.EnsureUIThread ();
global::ObjCRuntime.Messaging.void_objc_msgSend_IntPtr (This.Handle, Selector.GetHandle ("setAppearance:"), value.Handle);
}
```
which would throw an `NullReferenceException` if `value` is `null`
because the `[NullAllowed]` on the `PropertyInfo` was not considered when
generating the extension method - at least not for the call, the null
check was fine (and removed).
Reviewing the PR **requires** checking the bot-generated "Generator Diff" too.
Tests to be added along the binding fix for #5403
Note: this replace the (now closed) PR https://github.com/xamarin/xamarin-macios/pull/5415
reference: https://github.com/xamarin/xamarin-macios/issues/5408
First part to fix https://github.com/xamarin/xamarin-macios/issues/5416
We currently allow the `[NullAllowed]` attribute anywhere an attribute
can be used on metadata (i.e. no `AttributeUsage` is used).
However the generator only process the attribute in some specific cases,
*silently* ignoring others. This leads to situations such as
```csharp
[NullAllowed, Export ("setInputHandler:")]
void SetInputHandler (AUInputHandler handler);
```
where a `null` argument will throw an `ArgumentNullException` because
`[NullAllowed]` does not mean anything on a method declaration.
To avoid such confusion `[NullAllowed]` should be added on each parameter
(even if all of them requires it) and if a `null` return value is
possible then use `[return: NullAllowed]`.
This PR allows XI/XM bindings to be built, without error, when this
patch is applied.
```diff
diff --git a/src/generator-attributes.cs b/src/generator-attributes.cs
index 965d8469..77162253 100644
--- a/src/generator-attributes.cs
+++ b/src/generator-attributes.cs
@@ -250,6 +250,7 @@ public class IsThreadStaticAttribute : Attribute {
// When applied to a member, generates the member as static
// and passes IntPtr.Zero or null if the parameter is null
+[AttributeUsage (AttributeTargets.Property | AttributeTargets.ReturnValue | AttributeTargets.Parameter)]
public class NullAllowedAttribute : Attribute {
public NullAllowedAttribute () {}
}
```
Note that it's unlikely we'll apply this patch _as-is_ to avoid breaking
existing projects. A better approach (in a future PR) is to have the
generator (instead of the C# compiler) issue a warning (instead of an
error) when a `NullAllowed` is ignored.
As with other tests, this have been added because they were present when
we built the test assemblies locally, but they are not present in the
Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1132
As with other tests, this assembly was added when we built the tests in
the iOS makefile, but they are not present in the Mono SDK.
Fixes https://github.com/xamarin/maccore/issues/1140
One mono bump (6f2ebedb74 (diff-e801bb766cbaad95b50b1487b865f971)) changed our `Xamarin.iOS-FrameworkList.xml.in` (and the tvOS and watchOS ones) and added 2 files
```
<File AssemblyName="System.Buffers" Version="4.0.99.0" />
<File AssemblyName="System.Memory" Version="4.0.99.0" />
```
Around the same time this change was made in the IDE: e355f65870/main/src/core/MonoDevelop.Core/MonoDevelop.Core.Assemblies/TargetFramework.cs (L260)
That means that VSMac, when creating a new cache file listing the assemblies, won’t scan the assemblies in those directories `/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS`.
This resulted in an incomplete cache file missing most assemblies leading to the IDE showing red checkmarks for known and installed assemblies.
Ideally the FrameworkList files we ship should have a list of all the assemblies with PublicKeyToken and friends (the framework shouldn't be lazy and expect the IDEs to generate that file for us).
This commit ships a test using the same logic as the IDE to populate the FrameworkList file. The test will report any missing assembly and print the xml element that should be added to the file.
E.g: `<File AssemblyName="FSharp.Core" Version="3.98.4.0" PublicKeyToken="b03f5f7f11d50a3a" ProcessorArchitecture="MSIL" />`
Then it's only a matter of copy/pasting that (:
Note: even though this is the msbuild tests for iOS land I'm also scanning the Xamarin.Mac files here for simplicity.
We also scan all assemblies in `/Facades`.
Discussed in slack but adding all the facades assemblies doesn't compromise the project in the IDE (e.g: we still can't add incorrect assemblies) and it's required for some NuGet conflict resolution.
See: ac8fd9e60a
Before
```
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
clang : error : no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ee-interp.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-icall-table.a'
error MT5209 : Native linking error : clang: error: no such file or directory: '/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/lib/libmono-ilgen.a'
MTOUCH : error MT5202: Native linking failed. Please review the build log.
0 Warning(s)
7 Error(s)
```
After
```
MTOUCH : error MT0141: The interpreter is not supported in the simulator. Do not pass --interpreter when building for the simulator.
0 Warning(s)
1 Error(s)
```
Manuel de la Pena
Rolf Bjarne Kvinge
Sebastien Pouliot
Philippe Creytens
Bernhard Urban
Miguel de Icaza
Chris Hamons
Vincent Dondain