Otherwise the P/Invoke generator leaves partial results in the static
registrar class, essentially saying things like "we've processed CoreMidi, no
need to add an #include for this framework", and then we'd generate the static
registrar code and that code would lack the #include for CoreMidi.
Finishing the P/Invoke generator output will clear out any state stored in the
static registrar.
Also fix a few other issues to make the generated P/Invoke wrapper code work,
and add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/15190.
These changes correct some of the nullability attributes for the UIKit bindings. Although UIKit has several hundred lines of xtro-sharpie ignores related to nullability, this PR only fixes a few of them.
I wasn't sure where to draw the line, but in the end, I essentially fixed most of `UIViewController` and all of `UITableView` and `UICollectionView`. These classes were the ones that led to the most `// ReSharper disable` comments being added in my team's codebase, and/or that led to crashes being introduced by devs following ReSharper's suggestions to remove "unnecessary" null-checks.
These changes were largely based on the instructions given by @spouliot in [#6154](https://github.com/xamarin/xamarin-macios/issues/6154#issuecomment-620014843). However, I noticed the xtro-sharpie ignore files have been duplicated in the `api-annotations-dotnet` directory since then, so I updated the .ignore and .todo files in that directory as well.
If the process has changed since that comment was written, I can make any additional changes that are needed.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
* Confirm nullability in the ignore files
* use is null and is not null
* Remove unnecessary using statements for test
* undo the changes to the csproj
* remove monotouch-test.sln
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
* go through the nullable ignores and add test
* Enable Nullability
* use is null
* save a few lines
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
* Go through the ignore files and confirm nullability
* enable nullability
* throw better exceptions
* use is null
* remove from maccatalyst todo
* use a gethandle
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
The current directory at launch is the root directory of the app bundle. This
means that any files written to the current directory when an app is executed,
will be placed there. This becomes a problem when the app is rebuilt (and
resigned), because a valid macOS app bundle doesn't have any files in the root
directory of the app bundle, so signing fails.
We have logic to automatically crash crash reports from the app bundle, but it
turns out this is a more common problem with other types of files (and
folders), so improve the logic a bit:
* Add support for setting a property to automatically clean up everything from
an app bundle we don't think should be there (which is anything not in a
Contents/ subdirectory).
* Use the same property to add support for disabling any cleaning (we already
clean mono's crash reports by default).
* Improve detection of unwanted files to include directories inside the app
bundle, not only files.
Ref: https://github.com/dotnet/maui/issues/7353
I don't remember why I excluded watch apps, and it seems to work locally, so
let's see how it goes. Hopefully we'll get better diagnostics when something
goes wrong.
Remove our dependency on Visual Studio. Use the 'dotnet-t4' tool instead of
invoking the t4 tool embedded in Visual Studio.
Fixes this build error after installing VS Mac 2022:
> Cannot open assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe': No such file or directory.
This also means that we shouldn't load the linker's output. Note that we need
to check _LoadLinkerOutput even if we've already disabled the linker, because
there may be linker output from a previous (connected) build, and we don't
want to load that.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1542438.
* Handle 502 and 503 errors in the TrustUsingOldPolicy and TrustUsingNewCallback tests. Fixes:
[FAIL] TrustUsingOldPolicy : System.Net.WebException : The remote server returned an error: (503) Service Unavailable.
[FAIL] TrustUsingNewCallback : System.Net.WebException : The remote server returned an error: (503) Service Unavailable.
* Add more http and https urls to try (and don't use microsoft.com). Hopefully fixes:
[FAIL] WebClient_SSL_Leak : At least one url should work
This is a follow-up to #14943.
* A few tests seem to be failing rather consistently with network errors.
Rewrite these tests to try multiple urls before failing (we'll be assuming
that if one of the urls succeed, the other failures were network related).
* Rename the LinkAnyTest.WebClientTest to LinkAnyTest.WebClientTest_Http to
follow it's original intent, and make it test http instead of https.
* Remove unnecessary assertion from SSL_IP_5706. This is tested in plenty of other places.
Bots seems to break more often after this change, so let's see if this improves matters.
This is what happens with the bots:
We stopped hearing from agent [...]. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610
I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
Added code to:
compile a string to a platform library
collect the output of the compilation process
check for errors
Added a single unit test of the smoke test variety.
Add a default MAUI and a default Xamarin.Forms project as size comparison apps
(both created from templates).
This reveals that a MAUI app is ~30% bigger than a Xamarin.Forms app (42MB vs
31MB). Notably there's 21% *less* managed code, but 33% *more* native code.
https://gist.github.com/rolfbjarne/d294171969226f7511d90a817b9ac328
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>
We are going to be changing code in xharness. Is a good time to clean
things a little, make code more modern then enable nullability.
Try to get as much help from the new features and try to clean alittle
debt we have from the last time we moved code.
* remove null ignores and add nullability
* throw better exception
* use is null
* remove extra ignores
* Add the tests
* use a progma ignore instead
* revert monotouch-test.csproj
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
* adding Nullability
* throw better null exceptions
* use is null
* Added test
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Fix lookup of block proxy attributes to look in protocols declared on base classes.
Broken pseudo code:
class BaseApplicationDelegate : NSObject, IUIApplicationDelegate {}
class MyApplicationDelegate : BaseApplicationDelegate {
[Export("application:didReceiveRemoteNotification:fetchCompletionHandler:")]
public void DidReceiveRemoteNotification (UIApplication application, NSDictionary userInfo, Action<UIBackgroundFetchResult> completionHandler) { }
}
the static registrar wouldn't figure out that the DidReceiveRemoteNotification method
comes from the UIApplicationDelegate, because it would only look in protocols defined
on MyApplicationDelegate, not any base classes.
The fix is to look in base classes too.
Also:
* Fix a boolean logic error when matching parameters between methods in another
(rarely used) code path when looking for matching binding methods in the extension
class for protocols with optional members.
* Add tests.
Fixes https://github.com/dotnet/maui/issues/6259.
We can't return unretained INativeObjects to Objective-C, because they might
be freed at any point when the GC collects the managed object. Instead return
retained objects, that way they're not freed even if the GC collects the
managed object.
This fixes a random crash in the TestRegistrar.TestINativeObject when the GC
would run just after we've returned an INativeObject to native code, and later
used that native handle thinking it would still be valid.
Fixes https://github.com/xamarin/maccore/issues/2572.
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
Manuel de la Pena
Ryan Pendleton
TJ Lambert
Sebastien Pouliot
Steve Hawley
Chris Hamons
Frank A. Krueger
Eric Sink