Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258018 MonoObjects created, 235128 MonoObjects freed, so 22890 were not freed. (dynamic registrar)
There were 205809 MonoObjects created, 204221 MonoObjects freed, so 1588 were not freed. (static registrar)
This involves storing the out parameter in an additional variable, so that we
can still access it after the method call.
Before:
There were 257927 MonoObjects created, 235060 MonoObjects freed, so 22867 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 203983 MonoObjects freed, so 1717 were not freed. (static registrar)
After:
There were 257935 MonoObjects created, 235064 MonoObjects freed, so 22871 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 204006 MonoObjects freed, so 1694 were not freed. (static registrar)
Before:
> There were 205700 MonoObjects created, 113865 MonoObjects freed, so 91835 were not freed. (static registrar)
After:
> There were 205700 MonoObjects created, 113982 MonoObjects freed, so 91718 were not freed. (static registrar)
Step fwd to get the stativ page. We download all the artifacts from the
cascade pipeline. The artifacts are inherited thanks to the trigger.
Download, extract, print files to be removed.
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support
for MSBuild metadata - the CopyToAppBundle property - to avoid copying a
framework / dynamic library to the app bundle).
* Refactor MTouchTaskBase a bit to make parts of it reusable from the
LinkNativeCode task.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
The branch name will be:
* pr/branchname/branch_commit/buildid - for builds triggered by a pr
* ci/branchname/branch_commit/buildid - for all others.
Commit and build id have been added to ensure we have no collisions.
We already define it in the generated code, so the native compiler shows a warning:
Microsoft.macOS.registrar.coreclr.x86_64.m:1:9: warning: 'CORECLR_RUNTIME' macro redefined [-Wmacro-redefined]
#define CORECLR_RUNTIME
^
<command line>:2:9: note: previous definition is here
#define CORECLR_RUNTIME 1
^
Add changes to sync main into Localization branch
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Connor Adsit <cadsit@microsoft.com>
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
If can happen that when we bump xcode we do not get an api & generator
diff. This results in a set of cascading events that make the build
fail.
We know track when the result is not 0, store it in a var and pass that
variable to all the tempaltes that need it. The pwsh script already has
an if to check if the file if present and if not, it shows a warning.
* Make 'throw Objective-C exception' the default for managed exception marshalling.
* Make 'throw managed exception' the default for Objective-C exception marshalling.
* Disallow the 'unwind through native frames' option: CoreCLR won't do it.
* Disallow the 'unwind through managed frames' option: it's the safeset
option by far, and also matches the reverse case.
* Disallow the 'disable' option: this is also not safe, let's try to go the
safe route with CoreCLR.
* Change the default in native code too.
Partial fix for #10940.
Add stage names to the templates to use them in triggers in the future.
Remove a yaml file that turned out not to be needed (via a hack around
vsts limitations).
* Update to new linker custom steps API
* PR feedback
- Fix indentation
- Add Initialize(LinkContext) to ExceptionalMarkHandler
- Remove unnecessary ifdef
- Use IsSetter/IsGetter
- Use [0] instead of Single()
- Avoid allocating empty collections
* Note override issue
* Clean up comments
* Move `DynamicRegistrationSupported` change earlier, along with the
detection code.
This solve the issue that `ILLink` does a similar job _before_ we have
the chance to disable the dynamic registrar.
* ILLink does not support considering other attributes as `[Preserve]`
when it is itself preserved at the assembly-level.
This ignored test is checking that feature so it cannot be enabled
for `NET`
Added to known breaking changes https://github.com/xamarin/xamarin-macios/issues/8900
* Fix removal of the dynamic registrar on legacy
* Fix IntPtr size inlining
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
* Implement our xamarin_dyn_objc_msgSend[Super] overrides for ARM64.
* Modify mmp to use those overrides.
* Fix an issue with the existing xamarin_arm64_common_trampoline that caused
exceptions to not unwind correctly.
* Add an ARM64 variation of xammac tests in xharness.
* Various test fixes.
Adds a coherent parent dependency to `Microsoft.NET.ILLink.Tasks`, which
ensures that it will not be updated past the version included in
`Microsoft.Dotnet.Sdk.Internal`.
These changes allow us to remove our mono/linker darc subscriptions, as
`Microsoft.Dotnet.Sdk.Internal` updates will also bring in the latest
`Microsoft.NET.ILLink.Tasks` that the SDK references. This will reduce
the number of dependency update PRs created by maestro.
Since the `Microsoft.NET.ILLink.Tasks` and `Microsoft.NET.ILLink` NuGet
packages are created by the same build, we only need to track one of
these package IDs in eng/Version* files.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Enabling OneLocBuild to run every build we have on main because the Loc team will need the Loc artifacts to be published every time. By moving the conditional to the isPRSelected input, we will run the task every time but only create the PRs once a week!
The newly extracted `RegistrarRemovalTrackingStep` can be used inside
`dotnet-linker` to remove the dynamic registrar (if not required by some
other code).
We are using cascade pipelines, those are triggered automatically and
get all the artifacts. We create a json file that will be used by one of
the cascaded pipelines to make educated choices.
The test was merge with the xammac_tests in commit
93bbfe7a86
but we did not have the tests running to know.
This should fix some of the failures we have in older macs.
- Make git ignore the generated `report.md`
- Fix `.aotdata` reported total size in reports (was always 0)
- Add option to strip the dotnet app bundle (until [1]) so it's easier to compare with _oldnet_ sizes.
[1] https://github.com/xamarin/xamarin-macios/issues/11445
Create two pipelines that will be triggered when a new build is
completed and contains tests results. There are some important details:
1. pipeline triggers have to specify all branches or a subset. We use
tags to trigger for PRs.
2. Tags are and, not or, so we need to pipelines (lame lame).
Due to 2. we add a new tag to identify ci builds.
Do not publish the nugets that have been created in a PR build. The
build results can be accessed from the comment once completed. This way
we make sure that next builds do not have conflicts when publishing the
nugets.
This makes it easier to test localized strings used in mtouch, since we don't have
to replicate the build for all the resources.
This required a few changes to avoid including code in the mtouch tests that already
exists in the mtouch executable.
Also rename the mtouch test project to mtouchtests.csproj.
This way the test project can reference the actual mtouch.csproj without
causing conflicts due to having two projects with the same name.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
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.
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
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.
* 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.
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.
Makes this error show properly:
> error MM2301: The linker step 'Setup' failed during processing: This version of {0} requires the {1} {2} SDK (shipped with Xcode {3}). Either upgrade Xcode to get the required header files or use the dynamic registrar or set the managed linker behaviour to Link Platform or Link Framework SDKs Only in your project's Mac Build Options > Linker Behavior} (to try to avoid the new APIs).. String.Format failed! Arguments were: "Microsoft.macOS" "macOS" "11.3" "12.5". Please file an issue to report this incorrect error handling.
* Extract the code we use to configure the assembly resolver during a normal
mmp run to make it usable for --runregistrar.
* Configure the assembly resolver we use for --runregistrar.
* Pass the assembly resolver to the registrar so that it's actually used.
* Adjust the System.Void lookup to look everywhere even if we find a corlib,
since behavior changes a bit now that we're using an assembly resolver:
* Previous behavior:
1. In .NET mode, look for a corlib named System.Private.CoreLib, and fail to find it.
2. Look in all the loaded assemblies for System.Void (and find it in System.Runtime.dll).
* Broken behavior as a result of the resolver changes:
1. Find corlib as System.Private.CoreLib.dll
2. Fail to find System.Void in System.Private.CoreLib.dll, since we'd only look in corlib.
* New behavior
1. Find corlib as System.Private.CoreLib.dll
2. Fail to find System.Void in System.Private.CoreLib.dll, but find it in System.Runtime.dll,
since we're now looking in all the loaded assemblies.
This is required to make VSMac's usage of --runregistrar
VSTS already provides a status per job, since the governance tests do
not give much feedback in the comments and just set a status, we can use
the default provided by the VSTS app.
Remove those devices of Mac OS X that will not happen because we cannot
run the agent in such and old device. This is due to the fact that the
agent runs using c# and we do not support such and old OS.
Also add a new stage to run tests on catalina. ATM older OS as not
working, but Catalina should work with our trusted pool.
We move from having a status per nugets to two statues:
1. xamarin-macios (Nugets built) - to let us know that we did build
nugets.
2. xamarin-macios (Nuvets published) - to let us know tat we did pubish
the nugets.
On a pull request, Azure DevOps does not build the exact version of the code that you pushed,
but a version merged with your target branch. This means that the commit
we see in the Buid.Revision is not the one of the last commit of the PR,
which makes some statuses get "lost" and checks be missed.
We make a distintion on which variable to used base on the build reason.
* [mtouch] It seems watchOS simulators can automatically choose the right architecture from fat apps.
So we can build a fat simulator app, and not depend on mlaunch copying in the
specific architecture at launch time.
A partial fix for https://github.com/xamarin/maccore/issues/2411.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@d11721f55e [Xamarin.Hosting] Xcode seems to have changed some logic with regards to getting the primary instruments server. (#2416)
* xamarin/maccore@d27297a098 [Xamarin.Hosting] Don't copy single-arch executable over a fat executable. (#2417)
* xamarin/maccore@6c305d4aa7 [Xamarin.Hosting] Launching may succeed even if the launch request fails. Don't fail in that case. (#2415)
* xamarin/maccore@bccc91d6a0 Support ARM64 and ARM64e simulators (#2418)
Diff: c89fd6a694..d11721f55e
In this case we can obsolete the attribute on both legacy and dotnet
since the replacement attribute is available on both. However this does
require a small update to the legacy linker (and is part of the PR).
Fix https://github.com/xamarin/xamarin-macios/issues/10674
This avoid some computation that might not be needed.
It also avoids a `NullReferenceException` when updating to net6 preview 4
builds (where `ResolveType` can return `null` but the type reference was
enough to complete the job).
Rather than let the pipeline continue doing steps that do not make
sense, report the issue to be reviewed and reported to the bot admins.
The need of that template and extra env variable is due to the lack of
proper scripting in yaml so I have to get creative.
* Workaround dotnet/runtime#47533 and avoid listing required symbols when native libraries are dynamically linked
* Don't call LibMonoNativeLinkMode on macOS builds
* Apply iOS workarounds also for tvOS and Mac Catalyst
Because the maestro bot is not a team memeber AND cannot be added as
one, it will not trigger a PR build, but it will trigger an CI build. WE
make the changes to take those as PR builds and do them in the CI.
We allow to manually run the builds with no tests, yet we had some
expectations in following jobs. This commit makes sure we do not get
errors when not runnning the tests.
We are doing some black magic. We have several templates that
are executed with different parameters.
The problem with that is that templates cannot be used with the
matrix strategy, so we are doing a little trick based on the following:
1. We can create a template that expands.
2. We can use the each keyword, which allow a loop
3. yaml is a super set of json, therefore, it was jsond dictionaties
We use the parameters as yaml objs (simple json ones) and we pass them.
Now we can:
1. Add more tests with less typing.
2. Modify the tests when we manually trigger a build.
Yes! number 2 is very cool, do you want to remove a stage from a manual
build, just delete it. Do you want to change the device test labels,
just edit the object.
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
* [CI] Fwd labels and ensure dotnet tests are run when targeting main.
* Add 'run-dotnet-tests' to the tags to make manuel happy.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Remove the need to check if we are in a PR, just execute the translations when we are in main, that reduces the complexity of the condition and works.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
VSTS does not longer have a file with the pat yet it does allow to use
an env variable with the pat provided by the keyvault. Before this
change we have been running all the tests which results in several extra
hours when we do not need to. For example, if nothing was changed in
msbuild, do not run its tests which are 45 mins long.
Changes are:
* provide pat in the env.
* update xharness to use an env var, do not longer read from a file.
fixes: https://github.com/xamarin/xamarin-macios/issues/10923
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Manuel de la Pena
Rolf Bjarne Kvinge
TJ Lambert
Sebastien Pouliot
Sven Boemer
Peter Collins
Mike Bond
Connor Adsit
Filip Navara
Alex Soto
VS MobileTools Engineering Service 2