This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
That's what the _FrameworkNativeReference item group contains: framework binaries
instead of the framework directory itself. This makes us process frameworks in binding
packages correctly.
We're soon going to use this task to copy other types of directories (such as plugins)
as well, and in that case the old target name would be misleading.
Previously we'd only support passing in a fake reference to a file inside the *.xcframework.
This makes some other code simpler later on.
Best viewed by ignoring whitespace, since this is mostly whitespace changes.
* Update dependencies from https://github.com/dotnet/installer build 20211215.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.200-preview.21614.17 -> To Version 6.0.200-preview.21615.3
* Update dependencies from https://github.com/dotnet/installer build 20211216.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.200-preview.21614.17 -> To Version 6.0.200-preview.21616.3
* Update dependencies from https://github.com/dotnet/installer build 20211217.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.200-preview.21614.17 -> To Version 6.0.200-preview.21617.4
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Once upon a long time ago we decided to mark the properties in the
UITextInputTraits protocol as required in our API definition, because that way
we'd inline these properties in any class that implemented the
UITextInputTraits protocol, which made calling these properties much easier.
At a later point, we implemented better support for protocols, and now we
automatically generate extension methods for such properties (a corresponding
Get/Set method for the get/set property accessors), so we don't need these
inlined properties anymore.
However, removing them would be a breaking change, so we were stuck with these
redundant inlined properties, until .NET came along.
Ref: 0e80570863
Fixes https://github.com/xamarin/xamarin-macios/issues/5831.
Take into account any Bind attributes on optional property getters and setters
on protocols when generating the Get* and Set* extension methods, so that we
use the right selector.
Fixes https://github.com/xamarin/xamarin-macios/issues/12727.
The source code claims that having the different protocol hierarchy reduces
duplicate code, but I can't see what kind of code duplication this would
remove. The incorrect hierarchy causes all the UIScrollViewDelegate members to
not be inlined in UICollectionViewController, UICollectionViewDelegate and
UICollectionViewSource, effectively breaking API / source code, because this
might happen in UICollectionViewController subclasses now:
MyUICollectionViewController.cs(105,24): error CS0115: 'MyUICollectionViewController.DraggingStarted(UIScrollView)': no suitable method found to override
MyUICollectionViewController.cs(111,24): error CS0115: 'MyUICollectionViewController.DraggingEnded(UIScrollView, bool)': no suitable method found to override
This also debunks the claim from the comment in the api definition that
changing the protocol hierarchy would not be a breaking source change.
So go back to the correct protocol hierarchy for .NET, for all platforms.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
We're only building for Mac Catalyst on .NET, and this generated file is
entirely surrounded in a "#if !NET" condition, so not generating/compiling it
won't make a difference.
This makes it clearer what kind of types the method can handle.
A delegate constraint requires a newer C# version, which is why we can't do it
for legacy Xamarin.
This method exposes internal implementation details, and makes it difficult to
innovate in the runtime. Additionally it's purpose was always for diagnosis,
but I've never seen it used (not even for its intented purpose), so we can
just remove it for .NET.
Once upon a time there was a single VTCompressionSession.Create method, which
was [driving users insane][1] - they had to manually call CFRetain to avoid
crashes! What an abomination!!
Insane users are clearly not happy users, and we wanted happy users, so time
and effort went into creating a solution: a new Create overload was devised
and [implemented][1], taking extreme care to not break our brave and insane
existing users who had to manually call CFRetain. Because the fix would break
existing users - the now extraneous CFRetain would mean that their apps would
leak memory. *A lot* of it! That's bad, so we decided to make sure that didn't
happen.
Of course, dear old Murhpy wanted a say, so the new Create overload didn't do
as intended. In fact, it had the same insane behavior the old Create overload
had! Ops.
But Murphy decided to have even more fun: the changes were so buggy, that they
in fact fixed the old Create overload! Which from now on wouldn't require the
horrendous manual CFRetain calls... and effectively introducing the leak the
fix was trying so hard to not introduce.
Oh dear Murphy.
Of course he had another trick up his sleeve: in our extreme efforts to help
our users, we added an Obsolete attribute that would tell people to use the
new Create overload.
Let that sink in for a moment: we had an Obsolete attribute on a function that
was (now) perfectly fine, telling users to use a function that was broken.
To get the correct behavior, users would now have to to remove their manual
CFRetain calls, and ignore the obsolete warning on the old (and correct)
Create overload which told users to use the new (and buggy) Create overload.
In other words: still insanity, just a slightly different flavor.
Murphy had a field day!
Time went by, and eventually a sane enough user [reported the insanity to
us][2]. Even better: the user actually provided a fix! Truly, we have some
amazing users.
Unfortunately, the user didn't have access to our code history, and thus was
obviously not able to see the whole picture, and the fix ended up being
incorrect.
Unrelated lesson learned: don't forget your history, otherwise you'll end up
repeating mistakes from the past.
So now came the problem: how to fix all the APIs? In a way that didn't make
our users' existing apps just suddenly start crashing or leaking?
There really was no way, so nothing really happened for quite a while.
Then, an opportunity presented itself: we'd be able to do [widespread breaking
changes][3].
So, hoping that Murphy stays away this sunny winter day, I'm changing both the
new and the old Create overloads to do the right thing. But only in .NET,
where we can do breaking changes! Or at least that's my intention. I've tried
to stave off our dear old friend by adding his arch enemy: unit tests. Which,
of course, Murphy couldn't stay away from, but it seems adding a few
Thread.Sleep calls makes him bored enough to stay away. Hopefully for good...
[1]: 66c50b9a17
[2]: https://github.com/xamarin/xamarin-macios/pull/2070
[3]: https://github.com/xamarin/xamarin-macios/issues/13087
Rolf Bjarne Kvinge
dotnet-maestro[bot]
VS MobileTools Engineering Service 2
Mauro Agnoletti