The BackingFieldDelayHandler will temporarily remove the body of Dispose
methods, and then for every field accessed in the Dispose method that was
preserved by the linker, we'll keep the corresponding code in the Dispose
method (otherwise we'd remove the code).
This is a way to remove fields that are _only_ accessed (and nulled out) in
the Dispose method.
However, we were running into a problem with determining if a field was marked
by the linker: if the field is in a generic type, and that field was not
marked by the linker, the linker might have actually removed the field from
the containing type before we're processing the Dispose methods, and we'd find
a null field definition where no null field definition was expected
(eventually resulting in an ArgumentNullException).
Fix this by treating a null field definition as an unmarked field.
Also add a test.
Fixes https://github.com/xamarin/xamarin-macios/issues/16957.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
In our localization process, the Loc team builds the translations (in
the not-user-readable .lcl files) and merges them into the
'Localization' branch from a 'Lego/...' branch. After this happens, our
'Get Localization Translations' github action takes that commits and
creates a PR into main with those changes. It is really important that
this github action works because we will later delete the 'Localization'
branch and create a new one from the 'main' branch so that the branches
stay in sync.
There worked fine, but there is now a 'isDeletePrSourceBranchSelected'
input to the OneLocBuild task that defaults to true that deletes the
'Lego/...' branch right after the commit to 'Localization' is made. Due
to this, the github action cannot bring the commit to 'main' because the
'Lego/...' branch no longer exists.
The hope is that setting this input to false will successfully not
delete the 'Lego/...' branch allowing the rest of the flow to be
uninterrupted.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Fixes:
tools/common/PathUtils.cs(175,10): warning CS8981: The type name 'timespec' only contains lower-cased ascii characters. Such names may become reserved for the language.
tools/common/PathUtils.cs(180,10): warning CS8981: The type name 'stat' only contains lower-cased ascii characters. Such names may become reserved for the language.
We don't want to pass -force_load unnecessarily to the native linker, because
that defeats -dead_strip and makes apps bigger than necessary. So make sure to
honor the correct value for native libraries from binding libraries.
Ref https://github.com/xamarin/xamarin-macios/issues/16861.
Fixes this compiler warning:
tools/common/Driver.cs(302,14): warning CS0649: Field 'Driver.Jobs' is never assigned to, and will always have its default value 0
Don't add a dot after showing another exception message, because that another
exception message might also add a dot.
Example:
> An exception occurred while trying to invoke the function System.Void VisualStudioMac.AppDelegate.DidFinishLaunching (Foundation.NSNotification): Object of type 'CoreLocation.CLLocationManager' cannot be converted to type 'Foundation.NSNotification'..
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Fixes this on the bots when iOS is not enabled even though legacy is:
+ make -C /Users/builder/azdo/_work/1/s/xamarin-macios/tools/mtouch package-introspection-dependencies.zip
make: *** No rule to make target `../../runtime/.libs/iphonesimulator/libxamarin-debug.a', needed by `simlauncher32-sgen'. Stop.
Also add 'run-packaged-macos-tests' to the labels we care about.
This fixes an issue where the label combination
'skip-all-tests,run-packaged-macos-tests' would not run any tests.
I have been testing these changes inside the xamarin-macios-translations
pipeline.
The last run was green (found
[here](https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6984912&view=results)).
I had to use some placeholder code for the actual calls for the
OneLocBuild task that will communicate with the Loc Team but it reached
those points as expected!
This PR also rips out calls to the main-stage.yml template to only use
the stages necessary for the OneLocBuild run over the weekend!
I think these changes are set to see if the main branch can trigger the
OneLocBuild Task over the weekend build!
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Change the static registrar to fail gracefully if it can't compute a metadata token
for a given metadata item, and instead fall back to doing the lookup of whatever
we need at runtime.
This is a step towards making per-assembly static registrar working.
Ref: https://github.com/xamarin/xamarin-macios/issues/12067.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
A lot of code in our repo uses the presence of the BUILD_REVISION environment
variable to determine whether we're running in CI or not, so just set the
variable globally once so that it's always set - that way we never forget to
set it.
Note that the exact value of the variable doesn't matter, only that it's set.
Also change one place in the yaml that was depending on the contents of the
BUILD_REVISION to use the Azure Devops variable BUILD_SOURCEVERSION instead
(like we do everywhere else in our yaml code).
Allow to add a dependency before our build. This is used in the unified
pipeline to try to download the binaries if it can rather than building
from scratch.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When comparing with the previous commit, we can't use the TFM for the
stable version of .NET, since it may not be the same TFM used in the
previous commit.
Instead fetch the actual TFM from the checkout, and use that during the
api comparison.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Azure pipelines has this terrible design in which the path of the
checkout is different depending if you checkout a single repo or
several.
In this case, we have no issues on macios because we do know we have not
been checkout with anyother repo in the upload step, that is not the
case when working on the unified pipeline. Rather than adding some
complicated logic, we are going to be checking out the yaml templates so
that we have the same working directory structure.
It's often desired to run the install-workloads.sh script locally, in order to
diagnose problems with it.
So improve it a bit by:
* Adding a few comments explaining things.
* Don't assume we're in the correct directory.
* Figure out BUILD_SOURCESDIRECTORY if it's not already set.
* Validate a bit and show more helpful errors.
Hopefully future me will be grateful!
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
TJ Lambert
Manuel de la Pena