Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
The code to handle (and ignore) warnings was getting out of hand, so I've
unified it between all platforms. We now ignore the same warnings on every
platform, and have much fewer variables to reason about.
Move the class to its own file to simplify changes and code review.
Enable nullability in the class.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
* Enable nullability in NSHost, and fix misc issues.
* Add an explicit interface overload for IEquatable<NSHost>.Equals. Fixes this compiler warning:
error CS8767: Nullability of reference types in type of parameter 'host' of 'bool NSHost.Equals(NSHost host)' doesn't match implicitly implemented member 'bool IEquatable<NSHost>.Equals(NSHost? other)
Maybe a bad merge or we missed it.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Haritha Mohan <110641567+haritha-mohan@users.noreply.github.com>
Moved the extension methods to their own file and enabled nullable.
Fixed the following underlying bug:
The extension method that creates a valid parameter named does not do
the right thing in the following cases:
1. When the starting illegal char is NOT a number. It will prepend @
fixing nothing. Example " OHOH" to "@ OHOH"
2. When the illegal chars is in the middle of the param name. Example
"OH OH" to "@OH OH"
I have fixed the method to return null in those ocassions (we will need
to enable nullability later in the generator, is too much for this PR).
Tests have been added to ensure we do not have such an issue again.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Stop implying Mac Catalyst attributes from the iOS attributes, and instead
treat Mac Catalyst like all the other platforms (not implying anything from
any other platform).
This makes our attribute logic much easier to reason about and understand.
It also required adding numerous Mac Catalyst attributes that were previously
implied. This task was way too big to do manually, so I made some changes to
Chris' mellite tool, and managed to do it quite easily with Roslyn with the
changes in this branch: https://github.com/rolfbjarne/mellite/tree/explicit-maccatalyst-attributes
Add a Visual Basic templates for:
* All our platforms (iOS, tvOS, macOS and Mac Catalyst).
* A simple project (the ios, tvos, macos and maccatalyst templates).
* A class library property (the ioslib, tvoslib, macoslib and maccatalystlib templates).
Created a ticket asking the Localization team if they can control the
line endings before checking-in the code so that we will not have to
continue doing this:
https://ceapex.visualstudio.com/CEINTL/_workitems/edit/773212
---------
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
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.
This is the first part of a 2 or more changes that will allow the APIs
to use ? as a way to mark a nullable field, parameter, property and
return method.
The way it works follows the documentation from the runtime that can be
found here:
https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
The tldr; of the documentation is as follows:
1. If we are looking at a value type, the compiler converts int? into
Nullable<int>. This was already considered in the old code.
2. If we are inspecting a generic type we have to look for the
information in two different attributes added by the compiler: -
NullableAttribute: Each type reference in metadata may have an
associated NullableAttribute with a byte[] where each byte represents
nullability: 0 for oblivious, 1 for not annotated, and 2 for annotated.
- NullableContextAttribute is valid in metadata on type and method
declarations. The byte value represents the implicit NullableAttribute
value for type reference within that scope that do not have an explicit
NullableAttribute and would not otherwise be represented by an empty
byte[].
The API is very similar to that provided by dotnet6 but it allows us to
support classic. The move to the dotnet6 API should not be hard and
probably can be done by an IDE.
Once this API lands we will have to find the old usages of the check for
nullability and combine both. This new API should fix several issues we
have with nullability and nullability + generics.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Add overloads for request methods to provide a cleaner implementation.
Rather than passing a delegate, selector, and context info as separate
arguments, users can now use these methods with just a single delegate
parameter.
No manual tests were added due to methods requiring a physical device,
but created a [sample camera browser
app](https://github.com/xamarin/mac-samples/pull/146) to test
functionality of updated methods.
Fixes#5093
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Protocols with one set of introduced attributes ([TV (12, 0)]) inlined in
types that were introduced in a different version ([TV (10, 0)]) would always
use the attributes from the type.
This is wrong if the protocol was introduced after the type, in which case we
should instead use the introduced attributes from the protocol.
Fix this by choosing the latest introduced attribute when we have multiple to
choose from.
This required passing a bit more information around so that we always know if
a member is being inlined in another type.
This PR will also print availability attributes on the protocol members themselves:
[Protocol]
interface IProtocol
{
[TV (12, 0)] // this was not printed before
[Export ("someProperty")]
string SomeProperty { get; set; }
}
Also add and improve some tests.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/14802.
Fixes#17162
Added GPSLatitudeRef and GPSLongitudeRef to CGImagePropertiesGPS.
Added new photo to all resources folders that has GPS data.
Created new test that reads GPS information off a photo and verifies that it is correct.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The PrintAttributes method defaults to not printing anything, and when then
asked to not print platform attributes, it still adds up to doing nothing, so
just remove this redundant method call.
We used to show this:
> ILLINK warning MT1302: Could not extract the native library 'StaticLibrary.a' from '~/Downloads/BindingTest/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/StaticLibrary.a'. Please ensure the native library was properly embedded in the managed assembly (if the assembly was built using a binding project, the native library must be included in the project, and its Build Action must be 'ObjcBindingNativeLibrary').
now we show the assembly:
> ILLINK warning MT1302: Could not extract the native library 'StaticLibrary.a' from '~/Downloads/BindingTest/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/BindingLibrary.dll'. Please ensure the native library was properly embedded in the managed assembly (if the assembly was built using a binding project, the native library must be included in the project, and its Build Action must be 'ObjcBindingNativeLibrary').
Also increase diagnostics for this failure scenario to list all the resources
in the given assembly.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Fix an issue where it would not compute the correct grouping key for each member,
effectively grouping unrelated members together and coming up with weird and incorrect
results.
* Make it match failures exactly, which makes it possible to detect (and report,
which it now does) when a known failure is fixed.
* Ignore any hidden members (EditorBrowsableState.Never), because they're most
likely mistakes.
* Ignore any members in AppKit and UIKit, because these namespaces have a lot of
conflicting availability attributes. This is tracked in a separate bug (#17292).
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
This PR handles two scenarios (fixed in separate commits):
Scenario 1:
* The property has different availability attributes than the containing type.
* The property's accessor(s) do not have availability attributes.
We'd generate the wrong availability attributes for the property accessors,
because we'd take the type's availability attributes and add them to the
accessors.
As for the fix: I can't really explain it. This code is rather impenetrable,
and the parameter names don't make much sense, but whatever I did seems to
work?
And it turns out this fix shows up in an existing test as well (the
generator's Bug35176 test), which I had to modify to remove the expectation of
(now redundant) availability attributes that we no longer produce.
Scenario 2:
* Type is available on iOS, tvOS.
* Property in the type is available on iOS (and not tvOS).
* Property accessor has explicit availability attributes for iOS.
Then the property accessor would get the availability attribute for tvOS from
the type, and not the (un)availability attribute from the property.
The fix is to make sure the parent context is the property (and not the type)
when processing availability attributes for the accessor.
The bug manifests like this:
> Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded.
which happens because the SBNotificationHub doesn't exist in the final
executable. We asked the linker to link with the static library containing
this type, but the linker didn't link with the library because it didn't need
any of the symbols in it.
We should have collected all the exported Objective-C types from this library
and asked the native linker to keep them, but that didn't happen because:
1. We collect bound Objective-C classes from binding libraries here (the
ListExportedSymbolsStep): 608765e2c9/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs (L148-L157)
2. That only happens for attributes with a LinkWith attribute.
* We compute if an assembly has a LinkWith attribute here:
608765e2c9/tools/common/Assembly.cs (L266)
* Which is called from here:
608765e2c9/tools/common/Assembly.cs (L198)
* Which is called from here (the ExtractBindingLibrariesStep):
608765e2c9/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs (L18)
Now, we must obviously compute if an assembly has a LinkWith attribute before
doing anything that depends on that value, but we weren't doing things in that
order.
Changing the custom linker steps to run the ListExportedSymbols step *after*
the ExtractBindingLibrariesStep fixes this logic problem.
Fixes https://github.com/xamarin/xamarin-macios/issues/17347.
Try to fix #xamarin/maccore@2637 by making sure a file's timestamp changes
after make runs the corresponding target.
Otherwise it seems make may run into some sort of infinite loop.
Fixes https://github.com/xamarin/maccore/issues/2637.
Automated PR. Bring new translated changes in the lcl files for
OneLocBuild to create translated resx files.
Co-authored-by: Alex Hsu <csigs@users.noreply.github.com>
Co-authored-by: CSIGS <csigs@outlook.com>
Andoni Morales Alastruey
TJ Lambert
Manuel de la Pena
Rolf Bjarne Kvinge
Haritha Mohan
Steve Hawley
dependabot[bot]
VS MobileTools Engineering Service 2
dustin-wojciechowski
dotnet-maestro[bot]
Mauro Agnoletti
github-actions[bot]