Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
Fixes#17738
Addresses the initial issue of just documenting which properties are
tied to which configuration. But to make the documentation more helpful,
we should provide further context about what exactly these properties
mean. However, this isn't trivial as some properties are a bit
cryptic..once further info is acquired, it will be integrated in a later
revision.
Handle the 'need-repro' label like the 'need-info' label:
* Add a comment that we need a repro, and how to get one.
* Close the issue if no comments within 7 days.
* Add a 'need-attention' label if reporter comments.
Also add a document explaining how to create a repro, modeled after (copied)
MAUI's document (https://github.com/dotnet/maui/blob/main/.github/repro.md).
It's not used by anyone anymore, and there are better alternatives for .NET.
This removes a dependency on a private component, which makes a potential move
into the dotnet org easier.
AutoGeneratedName was a toggle to implement a certain (correct) behavior,
while at the same time not cause breaking changes.
Now that we can do breaking changes in .NET, we can remove the toggle (i.e.
the property), and just always do the right thing (that is: automatically
generate a _unique_ Objective-C name for Model classes, unless a name is
specified manually).
Ref: https://github.com/xamarin/xamarin-macios/issues/5107
* Add a configure option to use a locally built dotnet/runtime.
* Add documentation how to build dotnet/runtime the way we need it built.
* Modify our build to consume the custom dotnet/runtime if so configured.
This is useful when trying to debug the runtime locally, or trying out new
features there are no packages for yet.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233)
Diff: 424fa26148..ed6d146822
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
This optimization can be enabled when it's not possible to use the
managed linker (e.g. **Don't link**) or when the managed linker cannot
remove references to deprecated types that would cause an application
to be rejected by Apple.
References to the existing types will be renamed, e.g. `UIWebView` to
`DeprecatedWebView`, in every assemblies.
The type definition is also renamed (for validity) and all custom
attributes on the types and their members will be removed.
Code inside the members will be replaced with a
`throw new NotSupportedException ();`.
The msbuild test app `MyReleaseBuild` has been updated to test that the
optimization is working as expected (device builds are slow so reusing
this test has little impact in test time).
Basically the test ensure that `UIWebView` is used and cannot be removed
by the compiler (optimization) or the managed linker (since it's
referenced). Since the optimization is enabled then we can `grep` then
final `.app` directory to ensure there's no mention of `UIWebView` inside
any of the files that would be submitted.
The application can be run, by itself, and will turn green if OK, red if
`DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`)
or orange if a `NotSupportedException` is thrown.
Finally introspection tests have been updated to skip over the deprecated
(and renamed) types. It should not be an issue right now, since this
optimization is not enabled by default, but it made testing easier.
* [mmp] Don't ignore failures to execute pkg-config and simplify/improve logic.
* Show proper errors if pkg-config fails to execute.
* Extract logic to verify system mono version into its own function.
* Extract logic to execute pkg-config into its own function.
* Simplify code slightly.
* [mmp] Remove the MM5301 error message.
It's never used in mmp, and the same error code is already used in mtouch.
Using this option it's possible to test for the presence of a type
reference in both pre-linked and post-linked assemblies.
This makes it possible to detect if
* a 3rd party assemblies are using some specific type you would like to avoid;
* a type reference has been removed during the build (e.g. linker)
Notes:
* Custom attributes are encoded differently and not included in the assembly type references metadata.
* Assembly that define a type `X` do not have a reference (but the definition) of the type (and won't be reported).
If either the pre or post-linked warnings are not useful then it's possible
to add `-nowarn:150x` to exclude the results.
E.g.
* `-nowarn:1502` would not report references in pre-linked assemblies;
* `-nowarn:1503` would not report references in post-linked assemblies;
Finally `-warnaserror:150x` can be used to stop a build that would not
satisfy either the pre or post-linked condition.
* `-warnaserror:1502` would not report references in pre-linked assemblies;
* `-warnaserror:1503` would not report references in post-linked assemblies;
_side note_ same as https://github.com/xamarin/xamarin-macios/pull/7925
except that this one uses the localized mtouch/mmp errors only in master (so far)
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
Apple decided to expose most (but not all) `CIFilter` using protocols
(instead of weakly named dictionaries). Most of this maps well with
our strong bindings but there are cases where we:
* missing some properties (easy, there were added); or
* used a different types [1] and that requires new members / obsoletion
A few other API were also added in Xcode 11 (nothing in 11.1 or 11.2) and
included in this PR.
New introspection tests were also added to minimize the risk that
the API and generator changes produced incorrect code. This lead
to the finding of some missing API (in particular `Output*` properties)
that were added.
[1] Often ours are better (using `float` for a `bool` value is not
optimal) but we do not have `[BindAs]` for protocols :( to _fix_ them
Note: this replace draft PR https://github.com/xamarin/xamarin-macios/pull/7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
Tweak the watchOS architecture test to build for bitcode when building with
llvm, since that's what's usually done.
Also tweak the MT0145 error message a bit.
Fixes https://github.com/xamarin/maccore/issues/1994.
* [builds] add arm64_32 cross compiler
* [mtouch] force --interpreter on arm64_32 debug mode build
* [mtouch] include debug check for arm64_32 and reflect error codes in documentation
* [registrar] Report a warning when the registrar export an abstract INativeObject type to Objective-C.
Exporting abstract types to Objective-C can lead to problems when at runtime
we're asked to create an instance of such a type (which we can't), so warn
when this happens.
This would have caught #6655, and the problems explained in #4969 as well.
Since this may trigger for code that's currently working fine, I'm making it a
warning instead of an error (which means adding some extra code to be able to
easily report warnings from the generator code).
* Don't assume a TypeReference can be successfully resolved every time.
Also limit the output from the native compiler, so that we don't overload the
IDEs with output if the native compiler produces tens of thousands of errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/6526.
* [WatchKit] Remove this framework for iOS while keeping backwards compatibility. Fixes#6492.
* Copy all generated sources and modify them to throw PlatformNotSupported exceptions.
* Adjust some existing source code to also throw PlatformNotSupported exceptions.
* Sprinkle Obsolete attributes generously.
* Stop generating code for the WatchKit framework for iOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/6492.
* [introspection] Adjust test.
* [mtouch] Don't link with WatchKit, and show a warning if we detect code that want to use WatchKit.
* [xtro] Remove WatchKit for iOS.
* [introspection] Don't check obsoleted NSString fields for null.
There's probably a reason the field was obsoleted.
* [introspection] Add exception for the WatchKit framework.
* [xtro] Ignore obsolete enums.
There's probably a reason they're obsoleted.
In particular it solves a confusion between WKWebKit.WKErrorCode and
WatchKit.WKErrorCode: for iOS, the latter is obsoleted, and this way we always
process the former instead.
* [mtouch] Adjust wording for MT4178 to be more accurate.
* [WatchKit] Make more API obsolete/hidden.
Two classes managed to slip past the first time.
* [tests] Adjust test after WatchKit removal.
This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
So far this only applies to `QTKit`...
XM will now, by default, avoid natively link with QTKit unless it's
instructed to so explicitly using `--link-prohibited-frameworks`
ref: https://github.com/xamarin/xamarin-macios/issues/6039
This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
* [mtouch/mmp] Split out the RunCommand[Async] methods to a separate file so that the generator can reuse more easily.
* [generator] Show proper errors when failing to compile something.
* Fix grammar
Rolf Bjarne Kvinge
Haritha Mohan
Chris Hamons
Sebastien Pouliot
Vincent Dondain
michizhou
Bernhard Urban
Waleed Chaudhry
monojenkins