The main cause of the warning: "warning MSB6002: The command-line for the 'MTouch' task is too long" was the number of references that can be passed to `mtouch`.
Now all the arguments are written in a response file which in turn is passed to `mtouch`.
- Fixes bug #56501: MSB6002 command-line for MTouch task is too long, > 32000 characters
(https://bugzilla.xamarin.com/show_bug.cgi?id=56501)
- The response file is created in the device specific folder, as `response-file.rsp`. It is re-created every time.
- Added an msbuild test to ensure the response file is created by `GenerateCommandLineCommands` and that it includes all the references.
- Introduce `AddLine` and `AddQuotedLine` which we use to populate the response file (and go to the next line).
- Move to C# 7 syntax for string replacement.
- Update all tests in `MTouchTaskTests` to use the response file since the arguments are no longer passed directly to `mtouch`.
- Update MT0018's documentation for response files.
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
* [static registrar] Optimize creation of delegates for blocks.
Optimize creation of delegates for blocks so that it doesn't require the
dynamic registrar.
This is done by getting the metadata token for the Create method that creates
the delegate, and embed that metadata token in the generated code from the
static registrar.
Also add tests, since this scenario was not covered by tests already.
* [mmptest] Fix test after recent changes.
* [test-libraries] Avoid duplicate symbols.
* [tests] Update according to changes.
- https://github.com/xamarin/xamarin-macios/issues/3367
- App Store will now fail builds if you add in a 32-bit dylib
- If you are a 32-bit app you don't need the 64-bit part of your fat
dylib anyway
- Add --optimize=-trim-architectures to allow customization of behavior, as not everyone
uses app store
In addition, while writing tests for this is was noticed that mmp tests did not "really" run Release configuration correctly in most cases. Fixing this turned out to be a bit of a pain, but necessary to correctly test this (and other things).
- Turns out that /p:configuration:debug is not sufficient to tell mmp to
do the right thing
- That, in most projects, sets the DebugSymbols property, which really
is what is checked.
- However, two of our projects did not have that, so we always did
release mmp work.
- Removed configuration property for tests and added real "Release"
configuration option
Implement support for optimizing away the dynamic registrar.
* Add a new property (Runtime.DynamicRegistrationSupported) that indicates at
runtime whether dynamic registration is available.
* Check this new property whenever we need dynamic registration.
* Add an optimization to mtouch/mmp that detects whether dynamic registration
is required, and if not, changes Runtime.DynamicRegistrationSupported to
return false.
* Add an optimization to mtouch/mmp that inlines
Runtime.DynamicRegistrationSupported as a constant value.
The end result is that the linker will link away the dynamic registrar if
mtouch/mmp detects that it's not needed.
Benchmark
---------
I've compared the size of entire apps built for device:
|test | Before | After | Diff | % |
|:-----------------------------|-------:|-------:|-------:|------:|
|[monotouch-test/Release][1] | 95.7mb | 95.0mb | -680kb | -0.7% |
|[link sdk/Release][2] | 21.2mb | 20.9mb | -245kb | -1.2% |
|[minimalistic app/Release][3] | 4.58mb | 4.32mb | -259kb | -5.7% |
[1]: https://gist.github.com/rolfbjarne/3871e36d2de8db1a8eee1d9f9276d3d2#monotouch-test-release-wall-optimizations-enabled
[2]: https://gist.github.com/rolfbjarne/3871e36d2de8db1a8eee1d9f9276d3d2#link-sdk
[3]: https://gist.github.com/rolfbjarne/3871e36d2de8db1a8eee1d9f9276d3d2#minimalistic-app
Improved linker to:
* Not mark protocol interfaces by the mere virtue of having a type that
implements them. This is implemented by not marking protocol interfaces when
they're implementing a class, but instead when a method implementation is
found to implement a method from a protocol interface.
* Mark the wrapper type for protocols (this allows us to remove the Protocol
attribute, since that's the link between the protocol and its wrapper type).
* Remove the [Protocol], [ProtocolMember] and [Adopts] attributes.
The static registrar still needs some of the information linked away, so a few
changes are required to make it available post linker.
Generate table of protocols and their corresponding wrapper type in the static
registrar, so that we don't have to look for this information using the
dynamic registrar at runtime.
* [linker] Optimize calls to BlockLiteral.SetupBlock to inject the block signature.
Optimize calls to BlockLiteral.SetupBlock[Unsafe] to calculate the block
signature at build time, and inject it into the call site.
This makes block invocations 10-15x faster (I've added tests that asserts at
least an 8x increase).
It's also required in order to be able to remove the dynamic registrar code in
the future (since calculating the block signature at runtime requires the
dynamic registrar).
* [mtouch/mmp] Add support for reporting errors/warnings that point to the code line causing the error/warning.
Add support for reporting errors/warnings that point to the code line causing
the error/warning by adding ErrorHelper overloads that take the exact
instruction to report (previously we defaulted to the first line/instruction
in a method).
* [tests] Add support for asserting filename/linenumber in warning messages.
* Make all methods that manually create BlockLiterals optimizable.
* [tests] Create a BaseOptimizeGeneratedCodeTest test that's included in both XI's and XM's link all test.
* [tests] Add link all test (for both XI and XM) to test the BlockLiteral.SetupBlock optimization.
* [tests] Add mtouch/mmp tests for the BlockLiteral.SetupBlock optimization.
* [tests][linker] Make the base test class abstract, so tests in the base class aren't executed twice.
* [tests][linker] Don't execute linkall-only tests in linksdk.
The optimization tests only apply when the test assembly is linked, and that
only happens in linkall, so exclude those tests in linksdk.
* [tests][mmptest] Update test according to mmp changes.
Fixes these test failures:
1) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("inline-runtime-arch")
The warning 'MM0132: Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'inline-runtime-arch'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
2) Failed : Xamarin.MMP.Tests.MMPTests.MM0132("foo")
The warning 'MM0132: Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.' was not found in the output:
Message #1 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
Message #2 did not match:
actual: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size, blockliteral-setupblock.'
expected: 'Unknown optimization: 'foo'. Valid optimizations are: remove-uithread-checks, dead-code-elimination, inline-isdirectbinding, inline-intptr-size.'
* [tests][linker] Fix typo.
Fixes this test failure:
1) SetupBlock_CustomDelegate (Linker.Shared.BaseOptimizeGeneratedCodeTest.SetupBlock_CustomDelegate)
Counter
Expected: 1
But was: 2
* [registrar] Minor adjustment to error message to match previous (and better) behavior.
Fixes this test failure:
1) Failed : Xamarin.Registrar.GenericType_WithInvalidParameterTypes
The error 'MT4136: The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)'' was not found in the output:
Message #1 did not match:
actual: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<Foundation.NSObject>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
expected: 'The registrar cannot marshal the parameter type 'System.Collections.Generic.List`1<U>' of the parameter 'arg' in the method 'Open`1.Bar(System.Collections.Generic.List`1<U>)''
* [docs] mmp shows MM errors/warnings.
* [docs] Improve according to reviews.
* [tests] Fix merge failure causing test duplication.
* [generator] Teach generator about WrapAttribute on Getters and Setters
https://bugzilla.xamarin.com/show_bug.cgi?id=57870
`WrapAttribute` can now be used in property getters and setters,
this allows to Wrap virtually anything the way you need, for example
smart enums, consider the following API definition:
```csharp
// Smart enum.
enum PersonRelationship {
[Field (null)]
None,
[Field ("FMFather", "__Internal")]
Father,
[Field ("FMMother", "__Internal")]
Mother
}
```
```csharp
// Property definition.
[Export ("presenceType")]
NSString _PresenceType { get; set; }
PersonRelationship PresenceType {
[Wrap ("PersonRelationshipExtensions.GetValue (_PresenceType)")]
get;
[Wrap ("_PresenceType = value.GetConstant ()")]
set;
}
```
* Fix Feedback
* Fix doc error
* Update error message
* [ObjCRuntime] Add a BindingImplAttribute.
* [linker] Make ProviderToString an extension method on ICustomAttributeProvider to make it more discoverable.
* [generator] Use [BindingImpl] instead of [CompilerGenerated].
The entire diff is big (89MB), so it can't be gisted. However, most of it is
either removal of `using System.Runtime.CompilerServices;` or the change from
`[CompilerGenerated]` to `[BindingImpl (...)]` like this:
https://gist.github.com/rolfbjarne/8bfda3ed37b956d0342a1c1e9b079244
If I remove those parts of the diff, there's nothing significant left:
https://gist.github.com/rolfbjarne/4156164d6bdb1376366200394eb8a091
* [linker] Teach the linker about the new [BindingImpl] attribute.
In addition to the existing logic where the linker would optimize some
[CompilerGenerated] code (sometimes with additional requirements), it will now
also optimize all [BindingImpl (Optimizable)] code (without any additional
requirements).
* [tests] Add tests to make sure [BindingImpl (Optimizable)] works as expected.
* [linker] Check for [BindingImpl] before [CompilerGenerated] and stop checking for [CompilerGenerated] in XAMCORE_4_0.
Check for [BindingImpl] before checking for [CompilerGenerated], since the
former is more common.
Also stop checking for [CompilerGenerated] (at least to mean that code is
optimizable) in our next non-compatible evolutionary leap (XAMCORE_4_0):
* [introspection] Impl a better typo check.
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.
1. Add an --optimize flag to mtouch/mmp that allows users to select which
optimizations to apply (or not). This makes it easier to add future
optimizations, and allow users to disable any optimization that causes
problems without having to disable many other features.
2. Share as much optimization code as possible between mtouch and mmp. This
immediately gives a benefit to mmp, which has three new optimizations only
mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
dead code elimination.
This results in ~6kb of disk space saved for a linked Xamarin.Mac app:
* link sdk: [Debug][1], [Release][2]
* link all: [Debug][3], [Release][4]
Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.
[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64
* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.
* Fix whitespace issues.
* [doc] Document optimizations.
* Officially support optimizations by adding them to the Versions.plist.
* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.
* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
the Application's value will be incorrect when building fat apps (both
Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
does not depend on other instructions than the IntPtr.get_Size call, so
remove the checks that verify surrounding instructions. This makes the
IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.
* [tests] Add mmp tests for optimizations.
* [tests] Fix XM optimization tests.
* [tests] Fix test build error.
https://bugzilla.xamarin.com/show_bug.cgi?id=59294
This enables ImageRepresentation strong dictionary helpers.
--- A note about WrapAttribute
Whenever we use the `WrapAttribute` inside a `Category` we need to
include the `This` parameter as the first argument inside the Wrap
signature, like the following example:
```csharp
[Wrap ("WriteTiffRepresentation (This, image, url, format, colorSpace, options?.Dictionary, out error)")]
bool WriteTiffRepresentation (CIImage image, NSUrl url, CIFormat format, CGColorSpace colorSpace, CIImageRepresentationOptions options, out NSError error);
```
* [mtouch][mmp] Report invalid debug symbols files. Fixes#3200
Try to read the assembly with symbols and, if that fails, warn and
fallback to loading them without symbols.
This fixes cases were it's not easy to update or delete (e.g. nuget)
bad symbols files - so this cannot be an error without causing a lot
of pain.
However it needs to be reported, otherwise it wont be fixed (by the
publisher) and it can limit the debugability of the application and
the usefulness of the stacktraces.
Finally merge most of the resolver's code between mtouch and mmp so
we don't have to fix such issue twice anymore.
note: this needs to be slightly updated once we get a version of cecil
that can give us a more precise error message.
Also bring Rolf's tests from
https://github.com/xamarin/xamarin-macios/pull/3079
reference:
https://github.com/xamarin/xamarin-macios/issues/3200
When a method signature contains any ref/out parameters
it is a hint that this method is not a candidate to be
used with [Async] we now error BI1062 in the generator.
The reason of an error instead of a warning is that we
currently generate not compilable code when ref/out is
used on the method signature or in the signature of the
delegate (completion handler), it is very unlikely we are
breaking someone now that we emit an error instead of broken
code.
* Fix Anchor and Clarify the addition of BI1117 Warning into docs/website/generator-errors.md
BI1117 Warning documentation was missing from docs/website/generator-errors.md
so I added it.
- Add XIA0006: HttpClientAvoidManaged.
- Add documentation on how the rules work and how to activate them.
Also mention that they need to be ran on each active configuration.
- Bump maccore to include XIA 0006.
* [generator] Improve BI1014 - include name of unsupported field and update valid types on docs, fixes bug 57094.
https://bugzilla.xamarin.com/show_bug.cgi?id=57094
* Implement feedback
* fix error message
* More feedback
Detect MT1111 from mlaunch (which means mlaunch won't wait for the app to
exit), and instead use test run completion to determine test completion.
The main drawback is that if the test app crashes, it won't be detected (the
test run will time out, and reported as such), but it's still an improvement
over the current behavior (the tests may complete successfully, and still be
reported as timed out).
This also requires bumping maccore to get an updated mlaunch (one that reports
MT1111).
It does not make sense to create Xamarin.iOS projects that don't reference
Xamarin.iOS.dll, so make this an explicit error.
This fixes a NullReferenceException which could (when building for device, or
when not using simlauncher) occur, and instead shows the MT0123 error.
> MTOUCH : error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
> System.NullReferenceException: Object reference not set to an instance of an object
> at Xamarin.Bundler.Target.GatherFrameworks () [0x00065] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/common/Target.cs:122
> at Xamarin.Bundler.Target.ProcessAssemblies () [0x000c2] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Target.cs:802
> at Xamarin.Bundler.Application.ProcessAssemblies () [0x0002f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:1407
> at Xamarin.Bundler.Application.BuildManaged () [0x00001] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:831
> at Xamarin.Bundler.Application+<>c.<BuildAll>b__134_1 (Xamarin.Bundler.Application v) [0x00000] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x00024] in <48b95f3df5804531818f80e28ec60191>:0
> at Xamarin.Bundler.Application.BuildAll () [0x00050] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/Application.cs:779
> at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x00481] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:1420
> at Xamarin.Bundler.Driver.Main (System.String[] args) [0x0000f] in /Users/builder/data/lanes/5024/152b654a/source/xamarin-macios/tools/mtouch/mtouch.cs:945
https://bugzilla.xamarin.com/show_bug.cgi?id=59798
Bug #59570 was a dupe of #58063 but was harder (than it should be) to
diagnose because the error did not point out which assembly had the
issue (requiring a whole, large, customer solution to confirm).
This adds a new MT2103 error which points to the assembly that could
not be read.
E.g. VSfM will now show
> Error MT2103: Error processing assembly 'Shim, Version=2.0.1.0, Culture=neutral, PublicKeyToken=c55ec16d10c4b366': System.NullReferenceException: Object reference not set to an instance of an object (MT2103) (...)
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=59570
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=58063
* [mtouch/mmp] Downgrade MT0123 to a verbose log statement instead.
It's unlikely to be useful for normal people who've just set LANG for whatever
unrelated reason.
If it's needed to diagnose failures, it'll still show up in verbose logs.
* [docs] Remove MT0123, it's no longer being used, and we never released a version that used it either.
* [tests][mtouch] Update tests according to code changes (MT0123 removal).
* [mtouch/mmp] Set CultureInfo.CurrentCulture according to LANG.
This makes it easier to run mtouch/mmp under different locales when testing.
Unfortunately mono checks the system locale before checking LANG, which means
that there's no built-in way in macOS/mono to specify the current locale
without changing the system locale.
* [mtouch] Print verbosity using an invariant culture. Fixes#58849.
https://bugzilla.xamarin.com/show_bug.cgi?id=58849
* [mtouch/mmp] Fix error code.
* [mtouch/mmp] Log/warn when we set the current language.
* [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes#57966.
Also bump maccore to get an mlaunch error for launching a 32-bit app in a 64-bit-only simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=57966
* [tests][msbuild] Make sure all Info.plists have deployment targets.
Otherwise we get different behavior (32-bit allowed or not) depending on which
Xcode is used to build.
* [mtouch] Default to 64-bit arch if not specified and targeting iOS 11+.
* [tests] Tweak tests to either specify a deployment target < 11 or not build a 32-bit arch.
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes#51710 and #54417.
* Refactor required symbol collection to store more information about each
symbol (field, function, Objective-C class), and in general make the code
more straight forward.
* Implement support for generating source code that references these symbols,
and do this whenever we can't ask the native linker to keep these symbols
(when using bitcode). Additionally make it possible to do this manually, so
that the source code can be generated for non-bitcode platforms too (which
is useful if the number of symbols is enormous, in which case we might
surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
a per-symbol basis. This provides a fallback for users if we get something
right and we try to preserve something that shouldn't be preserved (for
instance if it doesn't exist), and the user ends up with unfixable linker
errors.
* Don't collect Objective-C classes unless they're in an assembly with
LinkWith attributes. We don't need to preserve Objective-C classes in any
other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=54417https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [mtouch] Make sure to only keep symbols from the current app when code sharing.
This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
Previously:
obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:12: error: expected identifier
@interface register : UITableViewController {
^
obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:21: error: expected unqualified-id
@interface register : UITableViewController {
error : Failed to compile the generated registrar code. Please file a bug report at http://bugzilla.xamarin.com
Now:
error MT4168: Cannot register the type 'register' because its Objective-C name 'register' is an Objective-C keyword. Please use a different name.
https://bugzilla.xamarin.com/show_bug.cgi?id=51776
* Update to mono 2017-04 branch
* Patch from Zoltan to fix build error with CppSharp.CppParser.dll
* Include new linker files in Makefile, based on mareks commit
* [msbuild] Fix running bgen for Xamarin.Mac.
bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.
* System.Data tests should act as if they are running on mobile profile
* Add --runtime=mobile to mono flags in Modern
* Move runtime launcher options up
* System.Data tests should use Mobile profile (mac fix)
* Bump 2017-04 to pick up AOT and assembly resolution fixes
* Build fixes for netstandard.dll and System.Drawing.Primitives.dll
The new handling went in with https://github.com/mono/mono/pull/4501.
I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.
* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS
* Fix 2.1/Facades/netstandard.dll build
* Fix the netstandard targets
* Bump mono to latest 2017-04 commit
* [xharness] Fix adding defines to csproj by correctly detecting existing defines.
* Bump mono to latest 2017-04 commit
* [mtouch] Update csproj with new files.
* [mtouch] Improve reporting for MarkExceptions from the linker.
* Bump mono to latest 2017-04 commit
* Bump mono to pick up latest 2017-04 branch commit (Fixes#55436)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436
* Add a missing Makefile dependency
* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time
(It is currently being applied for some configurations at runtime only)
* Bump system mono
* Bump mono for assembly loader changes
* Bump system mono
* Update assemblies list as some where moved to facades
6ca5ec442bc38e4d9220
* Bump mono to latest 2017-04 commit
* Add another new facade
* Bump mono to tip of 2017-04.
* Bump mono to tip of 2017-04.
* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes#56307 and #56308.
System.dll is now completely linked away unless the app actually uses any
System.dll API.
This is the change that caused this to change: 4960d5d2a2
Previously the following types would always be kept by the linker:
```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```
Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).
With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.
I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.
This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.
This means that the fix is to modify these tests accordingly.
https://bugzilla.xamarin.com/show_bug.cgi?id=56307https://bugzilla.xamarin.com/show_bug.cgi?id=56308
* Bump mono to latest.
* Fix merge conflict that was missed
* [mtouch] Renumber new error which clashes with an existing error number in master.
* [mtouch] Allow code sharing assemblies from multiple locations if they're identical. Fixes#56498.
We disallow code sharing when the same assembly (based on name) is referenced
from multiple paths, but poke a hole in this logic by allowing the same
assembly from multiple paths when those assemblies are 100% identical, since
that should be 100% safe.
https://bugzilla.xamarin.com/show_bug.cgi?id=56498
* [tests] Comment out assert that asserts due to another bug.
If both an extension and the container app (or multiple extensions) reference
the same binding assembly for a framework, then we'd error out with an
internal error when trying to copy the framework from both locations to the
container app.
So instead detect when we're trying to copy multiple identical (by comparing
the on-disk contents) frameworks, and only copy one of them.
We'll still show an error if the frameworks are different, but now a nice
MT1035 error with a proper error description instead of an internal error.
https://bugzilla.xamarin.com/show_bug.cgi?id=56635
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.
* Add XM SDK + LinkSkip test
* [macos] Add platform linking support to msbuild
* [macos] Add full SDK test
* [macios] Diable classic from using linkplatform
- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
It does not make sense to support incremental builds for the simulator (since
no AOT compilation is done), it just makes the test matrix more complicated.
So simplify things by removing support for incremental builds.
We also ignore any (other) --assembly-build-target arguments, because building
to frameworks doesn't make sense either in the simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=55712
We do support the use of [Async] on methods that do not return void,
we generate an overload with am out parameter to retrieve the returned value
```csharp
[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1)
{
var tcs = new TaskCompletionSource<bool> ();
var result = BarString(arg1, (obj_) => {
if (obj_ != null)
tcs.SetException (new NSErrorException(obj_));
else
tcs.SetResult (true);
});
return tcs.Task;
}
[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1, out string result)
{
var tcs = new TaskCompletionSource<bool> ();
result = BarString(arg1, (obj_) => {
if (obj_ != null)
tcs.SetException (new NSErrorException(obj_));
else
tcs.SetResult (true);
});
return tcs.Task;
}
```
Modified the introspection test to repor this, updated documentation
and update API definitions reported by introspection.
This is the first step for documenting the error messages in the generator:
create a document for the error messages.
The entries in the document are the same as the ones listed in the error.cs
file (which I've now removed to prevent duplication), with some very minor
editing.
The document is not yet published to the documentation repository (since this
is just the first step).
https://bugzilla.xamarin.com/show_bug.cgi?id=52570
In some cases you will find **static** members inside categories like in the following example:
```objc
@interface FooObject (MyFooObjectExtension)
+ (BOOL)boolMethod:(NSRange *)range;
@end
```
This will lead to an **incorrect** Category C# interface definition:
```csharp
[Category]
[BaseType (typeof (FooObject))]
interface FooObject_Extensions {
// Incorrect Interface definition
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
This is incorrect because in order to use the `BoolMethod` extension you need an instance of `FooObject` but you are binding an ObjC **static** extension, this is a side effect due to the fact of how C# extension methods are implemented.
The only way to use the above definitions is by the following ugly code:
```csharp
(null as FooObject).BoolMethod (range);
```
The recommendation to avoid this is to inline the `BoolMethod` definition inside the `FooObject` interface definition itself, this will allow you to call this extension like it is intended `FooObject.BoolMethod (range)`.
```csharp
[BaseType (typeof (NSObject))]
interface FooObject {
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
We will issue a warning (BI1117) whenever we find a `[Static]` member inside a `[Category]` definition. If you really want to have `[Static]` members inside your `[Category]` definitions you can silence the warning by using `[Category (allowStaticMembers: true)]` or by decorating either your member or `[Category]` interface definition with `[Internal]`.
* [generator] Have WrapAttribute generate virtual members
WrapAttribute now has a boolean optional parameter named isVirtual,
this instructs the generator to add the virtual keyword to generated
members.
This is useful when fixing breaking changes so we can keep the wrong
signature generated instead of having manual code files.
* [docs] Add docs about virtual to WrapAttribute
Warn if mtouch loads an assembly from a different location than requested
(which might be because there are multiple assemblies with the same name).
Also rework the MT0023 check a bit by explicitly loading the root assembly
first, and then detecting if any loaded assemblies matches the root assembly.
This results in code that's a bit more obvious, and it also works correctly
with extensions (previously the entire MT0023 check was skipped for
extensions).
The AOT-compilation occurs in the AOT-task now, and then we compile the result
using CompileTask.
This means that the error message in CompileTask was slightly incorrect, so
rectify it.
Create a custom AssemblyCollection class that contains a dictionary with
assembly identity (name) -> Assembly mapping.
This also means that we can detect if we end up loading multiple assemblies
with the same identity, and show an error in that case (even if that case
should never happen since we cache assemblies based on the identity, it's nice
to have code that ensures it).
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=52238
If you give mtouch/mmp a linker xml file with bad input for
example a Xamarin.iOS app and the linker.xml has a reference
to Xamarin.Mac instead of X.I.dll i.e.
<?xml version="1.0" encoding="UTF-8" ?>
<linker>
<assembly fullname="Xamarin.Mac">
<type fullname="ObjCRuntime.Constants"/>
</assembly>
</linker>
You will get a not so helpful generic error
MT2001 Could not link assemblies. Reason: Failed to process XML description: <unspecified>
It seems that when you use a xml file for linker you get a
`XmlResolutionException` from cecil when it fails to resolve
and the better error comes from the inner exception so we use
that instead.
New error output for XmlResolutionException:
MT2017: Could not process XML description: Failed to resolve assembly: 'Xamarin.Mac, Culture=neutral, PublicKeyToken=null'
Most projects building to bitcode (any kind of bitcode, this includes the
marker-only version as well), will fail to link when linking with third-party
libraries and incremental builds are enabled.
So automatically disable incremental builds when we detect this scenario.
This is only a workaround until we can make this scenario build correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=51710
* [generator] Add BindAs support for NSValue and NSNumber
https://trello.com/c/RYCPEnkh
The intent of BindAs attribute is to have a binding definition as
[return: BindAs (typeof (bool?))]
[Export ("boolMethod:")]
NSNumber BoolMethod (int arg1);
and our generator outputs
[Export ("boolMethod:")]
public virtual global::System.Nullable<bool> BoolMethod (int arg1) { ... }
So we internally do the NSNumber <-> bool conversion, this also
applies to properties, parameters and methods.
* [generator] Fix a small formating issue
* [tests] Add BindAsAttribute generator tests
* [generator] Implement @spouliot's feedback
* [tests] Add BI1048 and BI1049 error tests for [BindAs]
* [generator] Implement Rolf's suggestion to avoid almost all string comparisons in [BindAs] for types
* [generator] Add BindAs support for smart enums and arrays with tests
* [generator] Some code clean up and implementation of PR feedback
* [generator] Add Protocol|Model checks and tests also a NRE check in NSArray creator
BindAs attribute cannot be used in Protocol|Model interfaces
* [generator] Add NSNumber <-> Enum support
* [docs] add BindAs documentation
* [docs] Implement documentation feedback for BindAs
This allows mtouch to give better error message when something unexpected
occurs in the linker pipeline (at least for the sub-steps).
Practically it means fewer, contextless MT2001 errors. The replacements
error code are more precise, e.g.
* what was being done;
* what was being processed
and helps both diagnosing and, possibly, gives clues for workarounds
* [Doc] Introduce xamarin-analysis-doc-tool
This tool is responsible of producing the xamarin-analysis.md file which is
our Xamarin.Analysis rules documentation.
It will always override the content of the previous xamarin-analysis.md file.
We generate the documentation based on the existing rules in xamarin-analysis/shared/Xamarin.Analysis/Xamarin.iOS.Analysis.targets
Trello: https://trello.com/c/mKsUDti8
This adds a new overload to our Notifications class
Current:
public static NSObject ObserveDidStart (EventHandler<NSNotificationEventArgs> handler)
New overload:
public static NSObject ObserveDidStart (NSObject objectToObserve, EventHandler<NSNotificationEventArgs> handler)
This allows our users to have single object subscription to our
easy to find notifications.
Also this commit adds an Advice attribute encouraging to use the
Notifications class instead of the NSString based notifications
- `LoggingExtensions` has a new `MTError` extension method that helps generate
an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
The old `legacy` option will now be reported as a warning.
That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE).
This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls
Note: The BCL changes will happen in later stages.
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.
So make it a warning instead (and document what the user has to do to fix the
warning).
https://bugzilla.xamarin.com/show_bug.cgi?id=46552
Use metadata tokens instead of strings to find types and methods.
This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.
Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).
| | Before | After | Diff |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit | 102.810.144 | 102.609.456 | -200.688 = -0,20% |
| dontlink/64bit | 107.420.576 | 107.221.792 | -198.784 = -0,19% |
| linksdk/32bit | 40.957.296 | 40.936.864 | -20.432 = -0,05% |
| linksdk/64bit | 43.113.136 | 43.093.936 | -19.200 = -0,04% |
| linkall/32bit | 38.410.032 | 38.348.288 | -61.744 = -0,16% |
| linkall/64bit | 40.315.200 | 40.267.344 | -47.856 = -0,12% |
Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.
This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.
For a non-linked test app I get the following using the Xamarin profiler:
| | Before | After | Diff |
|-------------------|--------:|--------:|----------------:|
| Memory allocated | 2,8 MB | 2,4 MB | -0,4 MB = -14 % |
| Objects allocated | 43678 | 38463 | -5215 = -12 % |
| Private bytes | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.
The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.
E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites
mtouch (before)
Total time: 64202 ms
mtouch (after)
Total time: 34840 ms
* Add XM support for RemoveUserResourcesSubStep
* Tests supplied by @chamons
This makes it possible to set linker flags per assembly:
[assembly: LinkWith (LinkerFlags = "-lsqlite3")]
Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).
Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
Unify the code to determine whether a particular return type requires a stret
signature or not between the generator and platform assemblies.
Also fix the stret detection for armv7k, whose calling convention is not
identical to armv7(s): there's the concept of homogeneous structures, which
contains multiple elements of only one type, and which is sometimes passed in
registers on armv7k.
https://bugzilla.xamarin.com/show_bug.cgi?id=44709
* [tests] Remove Classic SDK tests.
* Remove XI/Classic support.
This also means we can remove support for the legacy registrars.
* [monotouch-test] Remove legacy registrar tests.
* [tests/mtouch] Remove Classic tests (and legacy registrar logic).
* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
The MT2001 error is a general, something went bad, in the linker code
base. The stack trace is often enough to track down issues but in some
cases it would be easier to ask customers for a specific assembly
(rather than their complete project) to investigate an issue.
Example:
error MT2103: Binding Optimizer failed processing `System.Void GoogleConversionTracking.Unified.GoogleConversionPing::.ctor()`.
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessIsDirectBinding (Mono.Cecil.MethodDefinition caller, Mono.Cecil.Cil.Instruction ins) [0x00026] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:264
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessCalls (Mono.Cecil.MethodDefinition caller, Int32 i) [0x00337] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:197
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.Process (Mono.Cecil.MethodDefinition method) [0x0007b] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:81
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00004] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:48
---
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00014] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:50
at Mono.Tuner.SubStepDispatcher.DispatchMethod (Mono.Cecil.MethodDefinition method) [0x0001d] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:215
at Mono.Tuner.SubStepDispatcher.BrowseMethods (ICollection methods) [0x0001c] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:167
at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) [0x0006b] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:145
at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) [0x00050] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:123
at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) [0x0000f] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:104
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00027] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/linker/Mono.Linker/Pipeline.cs:118
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) [0x000ac] in /Users/poupou/git/xamarin/xamarin-macios/tools/mtouch/Tuning.cs:79
Right now the MT2001 would only include the inner exception, which does
not include any clue to which assembly caused the exception.
Note: The same pattern to be applied to other BaseSubStep subclasses in
separate commits.
Related to (but not the fix for) https://bugzilla.xamarin.com/show_bug.cgi?id=44701
https://bugzilla.xamarin.com/show_bug.cgi?id=37175https://bugzilla.xamarin.com/show_bug.cgi?id=44322
Sometimes iOS API is returning objects of the wrong type for example
- (NSURLSessionDownloadTask *)downloadTaskWithRequest:(NSURLRequest *)request
It clearly states that it will return an NSURLSessionDownloadTask
instance, but yet it returns a NSURLSessionTask and we throw an
InvalidCastException when creating the managed object. This is
fine in ObjC but for us in a type-safety context is not.
Introducing ForcedTypeAttribute when applying this attribute
we will use GetINativeObject instead of GetNSObject which
the former does not perfom a type check on the underlying object
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
This allows us to convert some existing manual conversion code into
generated code and never miss a new constant being added [1].
The additional control comes in two forms:
* allow [Field (null)]: a null NSString constant will return this
enum value instead of throwing an ArgumentNullException;
* a new `[DefaultEnumValue]` attribute allow marking the constant to be
returned if the enum value is not known;
[1] Vincent found some missing in HomeKit when adding the new ones
from iOS 10.
This commits also adds documentation for the existing (missing) and
new attributes.
* [generator] Fix bug 43579 - Generator emits invalid code when using the same method name (overload) in @delegates using events and C# delegates
https://bugzilla.xamarin.com/show_bug.cgi?id=43579
Bug Description:
Generator will emit invalid code when using the same name (overload)
in a method inside a @delegate (protocol) that is decorated
either with EventArgs or DelegateName
-----------------------------------------------------------------
This commit introduces a new attribute named DelegateApiNameAttribute
which mimics the EventNameAttribute but for delegate properties in
host classes
It is used to specify the delegate property name that will be created when
the generator creates the delegate property on the host
class that holds events and delegates.
This is really useful when you have two overload methods that makes
sense to keep them named as is but you want to expose them in the host class
with a better given name.
example:
interface SomeDelegate {
[Export ("foo"), DelegateApiName ("Confirmation"), DelegateName ("Func<bool>"), DefaultValue (false)]
bool Confirm (Some source);
}
Generates propety in the host class:
Func<bool> Confirmation { get; set; }
This also introduces two new BIXXXX errors:
- BI1043 Repeated overload {mi.Name} and no [DelegateApiNameAttribute]
provided to generate property name on host class.
- BI1044 Repeated name '{apiName.Name}' provided in [DelegateApiNameAttribute].
Which provides an error instead of generating invalid C# code.
Generator test included :D
* [docs] Added DelegateApiNameAttribute and IgnoredInDelegateAttribute docs
Also added Protocol where Model was used in our docs so we do not
misslead customers about it
This is something that changed with 70f1346b: our libxamarin.dylib now
requires iOS 8+, which means the app itself must require iOS 8+ when using
libxamarin.dylib.
This fixes an msbuild failure (Xamarin.iOS.Tasks.IBToolLinking("iPhone").BuildTest):
Process exited with code 1, command:
/Applications/Xcode73.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -framework Foundation -framework UIKit /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonosgen-2.0.dylib /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libxamarin-debug.dylib -lz -isysroot /Applications/Xcode73.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -Qunused-arguments -miphoneos-version-min=7.0 -arch armv7 -shared -read_only_relocs suppress -install_name @executable_path/libXamarin.iOS.dll.dylib -fapplication-extension -o /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.dylib -x assembler /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.s -DDEBUG
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later (@executable_path/libxamarin-debug.dylib) for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
We need to compile the generated P/Invoke wrappers to a dylib, and link the
dylib for the product assembly (Xamarin.WatchOS.dll) with the generated
P/Invoke wrappers.
Since there might be P/Invokes in any assembly, just link in the P/Invoke
wrapper dylib for every assembly.
https://bugzilla.xamarin.com/show_bug.cgi?id=44048
Vincent Dondain
Rolf Bjarne Kvinge
Chris Hamons
Sebastien Pouliot
Alex Soto
Marius Ungureanu
Alex Soto
Timothy Risi
Sebastien Pouliot
Manuel de la Pena
Craig Dunn
Andi McClure
Vincent Dondain
Vincent Dondain