* [runtime] Call into managed code to handle runtime exceptions.
This makes things easier for CoreCLR.
There should be no significant performance hits; this code path is
exceptional, and exceptions are already very heavy-weight anyways.
* Update to use xamarin_free instead of mono_free as per review.
* Port more to managed code.
Create a new parameter that can be used to decide if we build or not the
dotnet parts of the project. If we do not, we make sure that we do not
have any errors in all the other steps.
A wrong implementation of a redirect was added and returns a 403 and not
a 302 resulting in an error. Update to the final destination of the
redirect and be happy.
fixes https://github.com/xamarin/maccore/issues/2432
We have to consider (setup and process) `libSystem.Globalization.Native`
in order not to remove the required symbols when stripping the native
executable.
Ignore `libSystem.Globalization.Native` for dotnet / catalyst
ref: https://github.com/xamarin/xamarin-macios/issues/11392
Build failures will now include things like this for quiet builds:
Tool xcrun execution finished (exit code = 1).
Undefined symbols for architecture x86_64:
"_GlobalizationNative_LoadICUData", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Ship all files published by 'dotnet publish' for bgen, not only files prefixed
by 'bgen*'. This way we ship Mono.Options.dll too (and we won't crash at
launch trying to look for it).
Fixes https://github.com/xamarin/xamarin-macios/issues/11269.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Use the jenkins script as a base to get the PAI & generator from stable
diff back to the CI. Comment is not perfect, but does provide the
required information. The comment can be improve in a later commit since
this is getting too large.
This seems to be required when running monotouch-test with lldb (!) - no idea
why it doesn't fail otherwise.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Remove 1 array allocation per print statement.
* Remove 2 string concatenations per print statement.
* Don't indent empty lines.
For the generated code for watchOS, this is the difference (time-wise I wasn't
able to measure anything significant, although the memory savings are
significant):
Before:
Allocation summary
Bytes Count Average Type name
535.485.544 7.115.025 75 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
110.149.624 1.238.394 88 System.Char[]
...
Total memory allocated: 1.793.323.536 bytes in 28.827.325d objects
After:
Allocation summary
Bytes Count Average Type name
494.592.328 6.624.441 74 System.String
145.340.480 2.270.945 64 IKVM.Reflection.CustomAttributeData
99.345.984 968.303 102 System.Char[]
...
Total memory allocated: 1.741.626.784 bytes in 28.066.650d objects
Difference:
Allocation summary
Bytes Count Average Type name
-40.893.216 -490.584 -1 System.String
0 0 64 IKVM.Reflection.CustomAttributeData
-10.803.640 -270.091 +14 System.Char[]
...
Total memory allocated: -51.696.752 bytes in -760.675 objects
This was measured by executing the following in an already built working copy:
/Library/Frameworks/Mono.framework/Versions/Current/bin/mono --profile=log:nocalls,alloc --debug build/common/bgen.exe @build/watchos.rsp
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* The generated static registration code will eventually be different.
* The generated code has to be compiled with different compiler flags.
This also required adding a new overload of xamarin_mono_object_release for the generated
code to compile.
This also meant reviewing calling code to make sure that MonoObject*s are
released when they should be, which meant reviewing every method that returns
a MonoObject*, and release the result.
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Native headers show it's null_resettable.
```objc
/// If set, the receiver will inherit the appearance of that object, as well as use KVO to observe its effectiveAppearance for changes. Typically this is used for child windows that are shown from a parent window or specific view. Defaults to NSApp.
@property (weak, null_resettable) NSObject<NSAppearanceCustomization> *appearanceSource API_AVAILABLE(macos(10.14));
```
For some reason, some of the internal hosted pools have been set without
the OS version (WRONG WRONG). The simples way is to allow to skip this
check in those pools over re-configuring all bots.
'We can lick gravity, but sometimes the paperwork is overwhelming.'
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
* monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the xamarinSetGCHandle🎏 / xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
* xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
We stopped converting full pdbs to mdbs on Windows, so we need to override the `DebugType` property to `portable` if it's `full`, otherwise the debugger won't work from Visual Studio.
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
Connor Adsit
Emanuel Fernandez Dell'Oca
Alexander Köplinger
Mauro Agnoletti
Peter Collins
Marius Ungureanu
Alex Soto