The default RuntimeIdentifier for Mac Catalyst is maccatalyst-arm64 if running
on an ARM64 machine, which is what our unit tests assume. Hardcoding the
RuntimeIdentifier in the project file prevents the default from being used,
and makes the unit tests fail when running on an ARM64 machine.
Extracted a good amount of code from Main3 which should make it easier
to read. Tried to keep changes minimal.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
The global variables cannot be loaded, this is reported by intro AND has
been tested with swift. Moved the variables to be an enum whihc makes
more sense in the API.
In theory we should define the default platform version if it's not specified
in the TFM, and this default should not change for a given .NET version:
* We release support for iOS 17.0 with .NET 8
* Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0
* .NET 9 is shipped, and at this point we bump the default to iOS 18.0
Basically: this should be the last OS version of the platform in question when
the current major .NET version is first released to stable.
Ref: 8e6394406d/accepted/2020/net5/net5.md (os-versions)
However, this doesn't work well for Apple platforms: whenever Apple releases
new Xcode versions, our existing workloads might not be compatible with the
new Xcode. We'll of course ship updateds workload with support for the new
Xcode, but defaulting to an older target platform version would mean that
developers wouldn't get the new workload, they'd get the old one. This is
exacerbated by the fact that Apple aggressively auto-updates Xcode on
developers' machines: they might wake up one day to a broken build - the
obvious fix ("dotnet workload update") doesn't fix anything - even if we've
shipped updated workloads - because the default is to use the old one. They'd
have to manually specify the target platform version in the target platform to
get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload
instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8
workload) - and then update _again_ when the next Xcode comes around. At this
point the point of having a sane default value is totally out the window,
because everybody would have to specify (and continuously update) a platform
version in their project files to keep their projects building.
So we've made the decision that the default target platform version is always
the latest target platform version.
Found this while writing some unit tests for the generator. The
comparison between types uses a ReferenceEquals, that means that we
should ensure that we have a EcmaType in both sides. When running this
on unit tests, we have a RunTime vs a EcmaType comparison which results
in an error.
Pay attention to the following:
1. Changed the way we filter types so that we can use the set in several
methods.
2. Added a new compiler injected attribute to be ignored:
'Microsoft.CodeAnalysis.EmbeddedAttribute'
3. Microsoft.CodeAnalysis.EmbeddedAttribute is added/present in more
than one assembly, so do not throw when that happens, is a special case
that is injected by the compiler.
I ran the generator diff between main and this commit and the output is:
```
diff --git a/old/dotnet/IDE/obj/common/bgen/bgen.AssemblyInfo.cs b/new/dotnet/IDE/obj/common/bgen/bgen.AssemblyInfo.cs
index ef5e2e112f..5ded00c3af 100644
--- a/old/dotnet/IDE/obj/common/bgen/bgen.AssemblyInfo.cs
+++ b/new/dotnet/IDE/obj/common/bgen/bgen.AssemblyInfo.cs
@@ -13,7 +13,7 @@ using System.Reflection;
[assembly: System.Reflection.AssemblyCompanyAttribute("bgen")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
-[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0+b60ee772c228723a5e01212471c1e8eb5c20ebb9")]
+[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0+ec8a6c261a68f6aee2ad2373cf45e3f001ac4679")]
[assembly: System.Reflection.AssemblyProductAttribute("bgen")]
[assembly: System.Reflection.AssemblyTitleAttribute("bgen")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]
diff --git a/old/dotnet/IDE/obj/common/bgen/bgen.sourcelink.json b/new/dotnet/IDE/obj/common/bgen/bgen.sourcelink.json
index 5c5105e606..547bfb2dc4 100644
--- a/old/dotnet/IDE/obj/common/bgen/bgen.sourcelink.json
+++ b/new/dotnet/IDE/obj/common/bgen/bgen.sourcelink.json
@@ -1 +1 @@
-{"documents":{"/Users/mandel/Xamarin/xamarin-macios/xamarin-macios/tools/comparison/tmp/src/xamarin-macios/*":"b454d454a6/*"}}
\ No newline at end of file
+{"documents":{"/Users/mandel/Xamarin/xamarin-macios/xamarin-macios/*":"b454d454a6/*"}}
\ No newline at end of file
```
API should result in no changes.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The packages in packages.config for mtouch don't seem be used anymore (the
localization process for mtouch doesn't use the xliff localization workflow
anymore), so just remove the file.
Adding up for review but will block its landing until the PR
https://github.com/xamarin/xamarin-macios/pull/7539 which was fixed by
@dustin-wojciechowski has been landed.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Also fix the signature for the Dispose method - it has to override the base
implementation, not provide a new implementation.
Contributes towards #15684.
The backslash character is pretty common on Windows (since it's a path separator),
but the argument parser will treat it as an escape character, and just skip it.
This is obviously wrong, so just replace backslashes with forward slashes, which
should work just as well on Windows, and will also be parsed correctly.
The downside is that now there's no way to escape characters, but that should be a
very rare problem (much rarer than backslash characters), and there are other
ways around the problem (set the actual target property instead of going through
the MtouchExtraArgs property for instance):
This makes it much easier to understand what's happening when there's a
failure to parse a binlog.
This happens rather frequently, these have all happened:
* Truncated binlogs because a build timed out.
* Binlog version is higher than expected.
* Bugs in the binlog reader.
* Bugs in the binlog writer.
Many, many, _many_ years ago (before my time!) Mono didn't properly handle
P/Invokes that returned structures. The arm ABI stated that certain structures
had be returned by having the function take a hidden first argument, where the
argument would be a pointer to where the returned structure should be stored
by the called function.
We worked around this in the generator by modifying functions returning
structures to functions taking a pointer to the function to return as the
first argument.
So this:
SomeStruct SomeFunction ();
would become:
void SomeFunction (SomeStruct *retval);
This workaround isn't necessary anymore, because both Mono and CoreCLR will
just do the right thing.
Except... when the the pointer to the structure must have a specific
alignment. In that case we still need the workaround, so keep it then.
There are a few issues with the bindings, because the typedef `UITrait`
in the headers is defined like this:
```objective-c
typedef Class<UITraitDefinition> UITrait
```
which means: "A Class that implements the UITraitDefinition protocol",
and not "The UITraitDefinition" protocol", which is how it was bound.
This means the corresponding bindings are incorrect, so fix them. In
some cases it's not possible to fix the API, so new ones had to be
implemented in order to maintain backwards compatibility.
Fixes https://github.com/xamarin/xamarin-macios/issues/19410.
This commit adds some missing bindings and fixes up some of the previous
API that were incorrectly bound with Vector4 instead of Matrix4.
A sample app using some of these latest bindings can be found here:
https://github.com/haritha-mohan/vision-analyzer
Contributes to https://github.com/xamarin/maccore/issues/2719, though
the manual testing ended up not being necessary still helped catch a few
bugs and showcases some of the latest work done for this Xcode release.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fix sending MidiPacket when MidiPacket has been created using a pointer to a byte[] rather than a byte[] passed as a reference.
MidiPacket.bytes used to be initialized to null, but that changed in a null-refactoring. Unfortunately code that dependend on the initial value being null wasn't updated, so the code regressed. Here we revert the old behavior by making the MidiPacket.bytes field nullable
Also add a test to make sure we don't regress this code again.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This is a follow-up to 2bd23381e64494f4dbdcfcd71d161365d111a780: there was
some missing logic that caused nothing to be done for Delegate fields backed
by a protocol interface.
Rolf Bjarne Kvinge
Manuel de la Pena
dustin-wojciechowski
dotnet-maestro[bot]
Emanuel Fernandez Dell'Oca
Haritha Mohan
jamesdlow