* Add nullability
* throw better null exceptions
* use is null and is not null AND fix spacing
* Rolfs suggestions and redo spacing
* missed a few spaces
* Found one more elusive space
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Bots seems to break more often after this change, so let's see if this improves matters.
This is what happens with the bots:
We stopped hearing from agent [...]. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610
Before:
$ make whatever
Print: Entry, ":ProductBuildVersion", Does Not Exist
After:
$ make whatever
The required Xcode (13.3) is not installed in /Applications/Xcode_13.3.0.app/Contents/Developer
Switch to getting mono-api-[info|html] from a newly created repository we
control and where we can easily fix issues, since mono/mono isn't getting many
fixes anymore. In the past I know I've been reluctant to look at these tools,
just because of the hassle of setting things up to debug, and then the
paperwork to get the fixes in mono/mono, and then backported to the branch
where we need them.
This repo has a few other benefits:
* The tools are built using normal projects, which means they're easy to debug
in an IDE (mono/mono's code has generated project files, which used in-tree versions
of the BCL, and it got quite complex quite fast).
* One fewer dependency on the mono archive, so we're getting closed to be able
to drop it completely when we drop support for legacy Xamarin.
* #13669 is already fixed there.
* It contains a few other misc fixes.
Fixes https://github.com/xamarin/xamarin-macios/issues/13669.
- Test is currently semi-manual and uses Alert to popup results
- Covers nint/nuint/nfloat with method/prop/field/event
- Execution currently doesn't execute events yet.
- Test fails due to reference issue reported to Steve
- Currently not hooked up to any automated tests
* This is a potential mitigation for slower transition to native code when
exception marshalling is enabled (#14812).
* A minor modification was required in the linker, to make sure any modified
assemblies are saved.
Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
Previously we'd compare the tip of the PR branch with the commit before merge commit into the target branch created by GitHub.
This doesn't work in the following scenario:
main gh pr
| G1 | (merge commit created by GitHub)
| / \ |
|/ \|
M2 |
| P2
| /|
| / |
| / |
| / |
|/ |
M1 |
| |
| P1
| /
| /
| /
| /
|/
We'd end up comparing P2 with M2, which is not what we want, because M2 could
have API changes that would show up as missing in P2.
It's actually even worse than that, because we could be in the following
scenario:
main gh pr
| G2 | (merge commit created by GitHub when api diff started)
| / \ |
|/ \|
M3 |
| P3
| |
| G1 | (merge commit created by GitHub when build started)
| / \ |
|/ \|
M2 |
| P2
| /|
| / |
| / |
| / |
|/ |
M1 |
| |
| P1
| /
| /
| /
| /
|/
And we still want to P2 with M2, but we'd compare P2 with M3.
We want to compare P2 with M1 instead. This is done by asking git for the
merge-base between P2 and M2.
This gets iOS integration tests passing
From what I can tell we are failing due to:
public static new PHLivePhotoViewAppearance GetAppearance (UITraitCollection traits) {
public static new PHLivePhotoViewAppearance GetAppearance<T> (UITraitCollection traits) where T: PHLivePhotoView {
having the same hash, as the generic constraints are not printed.
To solve this we take on a small (250ish) dependency on code from MonoMod.Common (MIT licensed). They have code which creates stable hash keys that include generic information.
Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler
when building a .NET project. This makes it possible to work around #14887 by
manually increasing the number of trampolines.
Ref: https://github.com/xamarin/xamarin-macios/issues/14887
Reworker previous to this PR was very Lazy is it's init process. In
many ways this was beneficial, but was tricky to get right and made
nullability attributes a nightmare to add. It also included multiple "null objects"
that would show errors only at the end of a conversion when writing the file.
I replaced it with a single-pass init system, where the module is read
and all required attributes are fetched before processing begins.
Two requirements to consider:
- We don't want to ModuleDefinition.ReadModule to be repeated
- We don't want to fetch all of the attributes if reworking is not
necessary, but need the ModuleDefination to know that
A static factory method `CreateReworker` only returns a reworker
if work is required. This way, there is never a half-loaded state
to consider.
Other:
- Renamed some fields to match standard coding convention
- Also update integration makefile to include new required args
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
When we compare assemblies with different names (such as Xamarin.iOS vs
Microsoft.iOS, or Microsoft.iOS vs Microsoft.MacCatalyst), we need to adjust
one the xml definitions to match the other with regards to the assembly name.
I'm very pleased to present full bindings to the MetalPerformanceShadersGraph framework!
I'm happy with how everything turned out with the exception of a few notes and questions below.
I re-implemented Apple's MNIST sample (from https://developer.apple.com/documentation/metalperformanceshadersgraph/training_a_neural_network_using_mps_graph) here:
https://gist.github.com/praeclarum/b8077771fb341a1f9c28240113e00425
It's also added as a unit test.
Fixes#14286
### Notes
* Although the API says it works on macOS 11, it has bugs and crashes with errors even with Apple’s Swift examples. It’s better on macOS 12. iOS 14 and on is fine.
* `MPSGraphSparseStorageType` has terrible names. They match Apple's but I wish they were better.
* I added convenience methods to `MPSNDArray` and `MPSGrapTensorData` and the `Variable` and `Constant` operations to decrease the amount of unsafe code users have to write. I currently do this for 32-bit floats, the most common data type.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Adjust our versioning scheme so that the NuGet version is
`Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish
version>") causes problems on branches producing stable builds, because each
new commit would end up with the same NuGet version, and we wouldn't be able
to push those to a NuGet feed because there might already be an existing
version there.
By using the commit distance in the NuGet version we ensure that every commit
has a different version.
We already have a few attributes that can specify the native name for a type, whenever the native name doesn't match the managed name:
* [Register ("DifferentClassName"): specifies the Objective-C class name
* [Native ("DifferentEnumName")]: specifies the Objective-C enum name (and also that it's a native-sized enum)
* [Protocol ("DifferentProtocolName")]: specifies the Objective-C protocol name
* [Category ("DifferentCategoryName")]: specifies the Objective-C category name
Unfortunately this leaves (at least) two cracks:
* Objective-C structs.
* Objective-C enums which aren't native-sized.
So I'm adding a [NativeName] attribute for this purpose, and updating numerous
types to specify the native name (either using an existing [Native] attribute
for enums that already have one, or by adding a new [NativeName] attribute).
The static registrar needs to know the native name for such types, in case
they appear as parameter types in function signatures.
This also allows us to simplify xtro a bit, to not have a separate map of
managed name given a native name, because we can now build that map
dynamically.
Added code to:
compile a string to a platform library
collect the output of the compilation process
check for errors
Added a single unit test of the smoke test variety.
We need to be able to embed the dlls as a resource to compare the diff
assemblies. To do so we are going to ensure that we have called make in
the root dir so that the needed deps are present. This change is not yet
in the csproj, that will be a diff commit.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Manuel de la Pena
TJ Lambert
Rolf Bjarne Kvinge
Chris Hamons
Steve Hawley
Frank A. Krueger
Mauro Agnoletti
dotnet-maestro[bot]
Emanuel Fernandez Dell'Oca