Sadly that was not enough to trigger the typo detector test. It's also
part of a protocol, which means a .net interface so it cannot be fixed
without a breaking change. As such the fix is under `XAMCORE_4_0`
Fixes https://github.com/xamarin/xamarin-macios/issues/3272
Fixes this warning:
> Makefile:317: target `/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS' given more than once in the same rule.
because the same directory was listed twice.
* [runtime] Remove specialized function for getting the Selector/Class handle of a managed Selector/Class instance.
The existing function to get the handle of an INativeObject works just as fine.
* [runtime] Store and use a prebuilt XamMacLauncher.
Some changes in the runtime needs corresponding changes in XamMac.dll, but
since we're not changing XamMac.dll anymore, we can't change the runtime
either.
This means that we must add XamMacLauncher to the list of binaries we copy.
* [runtime] Store and use a prebuilt libxammac*.a as well.
* [mtouch] Make sure the xamarin_localized_string_format* functions are available in simlauncher. Fixes#3265.
Fixes https://github.com/xamarin/xamarin-macios/issues/3265.
* [mtouch] Add test for simlauncher symbols, add add more missing symbols.
Fixes this rather puzzling build problem when building monotouch-test using xharness:
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs(2,12): error CS0579: Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute
It happens only on Wrench (where it consistently fails), but it didn't happen
in the PR when this broke, nor could I reproduce it locally at first.
Initial investigation proved frustrating (searching for the file name
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` in the build log confirmed
that it was included multiple times on Wrench, but not locally), but after a
while I realized that there were multiple files with the same file name in the
build log:
/Users/builder/data/lanes/1381/daf07005/source/xamarin-macios/tests/monotouch-test/obj/iPhone/Release64-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
One full path, and one relative, and one is obviously wrong.
Even more so once I realized that the full path's Platform/Configuration
(`iPhone/Release64-unified`) doesn't match the relative path's
Platform/Configuration (`iPhoneSimulator/Debug-unified`).
It's not even a test configuration we execute on Wrench, so how come the file
got there in the first place?
But it made it possible to reproduce locally: I just had to build monotouch-
test for device first, using tests.sln. Then I could reproduce the build error
when executing monotouch-test from xharness, since now I had the extraneous
file on my file system.
xharness will clone project files (to avoid parallel issues when building
multiple projects in parallel, all projects are built in their own
directories), and it turns out we didn't properly fixup all paths.
In particular the following:
<Compile Include="**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
would be transformed into:
<Compile Include="\Users\builder\data\lanes\1381\daf07005\source\xamarin-macios\tests\monotouch-test\**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
which meant that we'd include all files recursively in the monotouch-test
directory, excluding files from the project file's obj sub directory. And
since the project file was cloned, it would be in a different directory, and
thus not able to exclude files from the original monotouch-test/obj directory.
And with this knowledge the simple oneliner to fix it was trivial.
One mystery remained though: how was the extraneous
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` file generated when we don't
execute device tests on Wrench? After a while I remembered that the MTouch
tests build monotouch-test for device, even though they're not executed.
And this explains why the problem happens on wrench only: Jenkins didn't
execute the MTouch tests.
The original, now obsoleted, `LocalizedString` API returned a .net
`string` which does not work in most cases.
Different versions of iOS seems to return different (public or internal)
subclasses of `NSString` that are understood by other API (like NSString
`localizedStringWithFormat:`) for further customization.
Our logic to convert NSString to string is correct but it cannot
recreate the custom, required subclass to continue the localization.
So the new API return an `NSString` publicly (which is actually a
subclass) that can do the required job.
Adding a test in monotouch-test is presently blocked by #3265 [2]
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=41292
[2] https://github.com/xamarin/xamarin-macios/issues/3265
* Add tests for new (and old) NSBundle API and adjust old ones since adding a Base.lproj directories changes things
* Add localization to xammac_tests since it shares the same, updated tests
When determining the color for a collection of tests, first check if the
execution result is identical for all tests in the collection, in which case
just use the corresponding color for a single test.
Instead of hard-coding the platform as iOS for the EmbedMobileProvision
task, use the SdkPlatform to determine the appropriate platform to use
in the MobileProvisionIndex query.
This is a follow-up fix with near identical changes to the
CompileEntitlements fix for tvOS.
Instead of hard-coding the platform as iOS for the EmbedMobileProvision
task, use the SdkPlatform to determine the appropriate platform to use
in the MobileProvisionIndex query.
This is a follow-up fix with near identical changes to the
CompileEntitlements fix for tvOS.
- Fixes bug #59272: [xtro] Report !missing-protocol-conformance! when protocols are defined in categories
(https://bugzilla.xamarin.com/show_bug.cgi?id=59272)
- Implemented missing protocol conformances based on tool's new data.
- Remove Internal check from VisitObjCCategoryDecl and VisitObjCInterfaceDecl
- Ignore previewItemTitle failure (normal since it's optional)
- Only skip UIStateRestoring for subclasses of UIViewController
- Ignore UIStateRestoring test on watchOS (UIViewController not available)
- Remove protocol conformances that generated wrong availability attributes (https://github.com/xamarin/xamarin-macios/issues/3213)
- Avoid new virtual or virtual when adding protocol conformance (https://github.com/xamarin/xamarin-macios/issues/3217)
xharness needs a solution in order to ask for a nuget restore, so make sure to
provide the path to the solution.
This fixes a build issue where the install source tests would fail to build
due to picking up the system's nunit.framework.dll because the nuget one
wasn't found/restored:
MonoPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
XamarinSourcesPathManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
PathManclerFactoryTests.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.'
OpenTKManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(29,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(30,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(31,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(33,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(35,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(36,4): error CS0616: 'TestCase' is not an attribute class
OpenTKManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(37,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(38,4): error CS0616: 'TestCase' is not an attribute class
MonoPathManglerTest.cs(39,4): error CS0616: 'TestCase' is not an attribute class
XamarinSourcesPathManglerTest.cs(47,4): error CS0616: 'TestCase' is not an attribute class
These targets will already be properly escaped (using backslash), so adding
quotes will cause make to treat the backslashes literally (and break).
Fixes an issue with package-tests:
$ make package-tests
[...]
build-mac-classic-dont\ link failed
build-mac-unified-dont\ link failed
build-mac-unifiedXM45-dont\ link failed
build-mac-unified32-dont\ link failed
build-mac-unifiedXM4532-dont\ link failed
build-mac-unified-link\ all failed
build-mac-unified-link\ sdk failed
make[4]: *** [build-mac] Error 1
make[3]: *** [mac-test-package.zip] Error 2
make[2]: *** [package-tests] Error 2
* [xharness] Run monotouch-test both with and without the static registrar in the simulator.
This way we catch (some) problems with the static registrar without having to run on device.
* [xharness] Add comments to explain extra test configurations.
* [xharness] Fix how projects are cloned.
Fix how projects are cloned so that xharness doesn't end up confused when
multiple test tasks share the same build task.
Previously xharness would iterate over all test tasks and modifying their
build tasks, now it will create the build tasks correctly in the first place.
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);
```
If the assembly is registered in the static registrar, skip it before trying to probe whether it has a reference or not. A dictionary lookup is way faster than probing the referenced assemblies
* [tests] Add 'link all' test for XM.
* [tests] Add 'link sdk' test for XM.
* [tests] Move dontlink-mac tests to linker-mac directory to have the same directory layout as linker-ios.
These were accidentally not disabled when we started running tests on Wrench
like we do on Jenkins.
So disable them, to avoid duplicate work on Wrench.
We already have the information we need to generate these function
declaration, so this prevents the need for keeping information in two
different places up-to-date.
Caching the result of checking whether a type is a CIFilter or not in a
dictionary makes the total time spent in the method go down to approximately a
third (11ms to 3ms) when linking monotouch-test on my machine.
and ensure the temporary `NSString` instance is disposed asap.
Found will debugging something else. Unit tests added to confirm there
is no behavior change when the API are used.
Previous behavior
=================
* The linker would determine if a class is a generated binding class or not.
This was determined by the presence of a constructor taking a single IntPtr
argument, and with a [CompilerGenerated] attribute.
* If a class was not a generated binding class, then that class and all its
superclasses were marked as not optimizable (in the context of inlining the
IsDirectBinding check).
* The end result was that all classes with a [CompilerGenerated] IntPtr
constructor that weren't subclassed, were optimized (the IsDirectBinding
value was implied to be 'true').
Unfortunately this does not match how the IsDirectBinding value is actually
computed, and is in many cases quite wrong.
Background
==========
The authorative value for the IsDirectBinding value is the register attribute:
```csharp
[Register ("MyClass", true)] // the second parameter specifies the IsDirectBinding value
class MyClass : NSObject {}
```
Due to history this second parameter is called `IsWrapper` and not
`IsDirectBinding`, but it's the exact same thing.
Unfortunately looking up this attribute every time a class is instantiated is
slow (since fetching attributes is slow), so we guess this value in NSObject's
initialization: if the actual type of the object is in the platform assembly,
then we assume IsDirectBinding=true:
```csharp
IsDirectBinding = (this.GetType ().Assembly == PlatformAssembly);
```
and any subclasses in the platform assembly which is not a direct binding have
to set the correct value in their constructors.
New behavior
============
In the linker we now track three states for the IsDirectBinding value for each
class: if it can be inlined into a constant true or false, or if it has to be
checked at runtime (a nullable bool is used, and null corresponds with this
last undetermined state).
* The linker will look at the `[Register]` attribute for a class, and:
* If the type is CIFilter, store that IsDirectBinding=undetermined.
* If IsWrapper=False, store that IsDirectBinding=False for that class, and
that IsDirectBinding=undetermined for all super classes where
IsWrapper=True.
* If IsWrapper=True, tentatively assume IsDirectBinding=True in that class
unless already determined to be undetermined (which will be overruled if
a non-wrapper subclass is found later).
Results
=======
For monotouch-test, the changes are as follows:
* Classes we can now assume IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L1-L25
* Classes we previously assumed incorrectly that IsDirectBinding=true: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L27-L645
* Classes we can now assume IsDirectBinding=false: https://gist.github.com/rolfbjarne/acd6a8cf1236562a832d6db9400afee9#file-foo-diff-L647-L2281
There are also minor size improvements (in the iPhone/Debug64 configuration):
The executable is 17.632 bytes smaller:
-rwxr-xr-x 1 rolf staff 73038384 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 73020752 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/monotouchtest
Xamarin.iOS.dll is 3.072 bytes smaller (this will probably be 0 on a release (stripped) build).
-rw-r--r-- 1 rolf staff 2522624 Jan 12 12:40 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2519552 Jan 12 12:50 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
CIFilter
========
There's a complication with CIFilters [1] [2], their implementation is
somewhat special, so we do not want to optimize anything for those classes to
not risk getting anything wrong.
[1] https://github.com/xamarin/xamarin-macios/pull/3055
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=15465
* [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
* [msbuild] DetectSigningIdentity fix for Mac when RequireProvisioningProfile is false
Fixes https://github.com/xamarin/maccore/issues/612
* Disable some tests since they don't make correct assumptions anymore
* Added comment to explain why tests are disabled
* [msbuild] DetectSigningIdentity fix for Mac when RequireProvisioningProfile is false
Fixes https://github.com/xamarin/maccore/issues/612
* Disable some tests since they don't make correct assumptions anymore
* Added comment to explain why tests are disabled
This now formal `CAAnimationDelegate` protocol had to be reverted [1]
because we did not support `FormalSince` at the time - and this broke the
static registrar when used with older SDK. Support was added in [2] but
did not include `CAAnimationDelegate` (but `CALayerDelegate` was fixed).
Because this was not a protocol the `Delegate` property expose it as a
`CAAnimationDelegate`, the concrete/model type, and not an interface.
The workaround so `ICAAnimationDelegate` can be used, thru the
`WeakDelegate`, requires to manually re-bind some API because the
generator won't allow this anymore (it's bad to expose a [Model]
when a [Protocol] exists).
xtro data updated
[1] https://github.com/xamarin/xamarin-macios/pull/698
[2] https://github.com/xamarin/xamarin-macios/pull/2130
In particular the mmp tests build a lot of project files, which means they can
find issues whenever something in the MSBuild logic changes, so run them.
They would have caught https://github.com/xamarin/maccore/issues/612 for instance.
Fixesxamarin/xamarin-macios#3166
Apple broke `addAnimation:forKey:` API by changing `CAAnimation` parameter into a
`ISCNAnimationProtocol` that was introduced in Xcode 9 (iOS 11 and company).
We can't break the existing API but we can add an extension method that
reuses the `CAAnimation` overload but takes a `SCNAnimation` and we
turn the `SCNAnimation` into a `CAAnimation` behind the scenes.
For XAMCORE_4_0 we corrected the protocol signature to take `ISCNAnimationProtocol` so there won't be a need for the extension method anymore.
* [linker] Refactor and simplify code optimizations.
We had several types of code optimizations, where we'd determine a particular
expression is a constant, then remove the condition and the code for any
dead branches.
Unfortunately each type of expression had its own logic to determine the
sequence of code to remove, each slightly different depending on the actual
conditional expression. This has led to bugs in the past, either when
switching between compilers (mcs/csc), or compilers have changed their emitted
code.
So implement a more generic version where each optimization just changes the
specific condition to a constant value, and then at the end we have a dead-
code-elimination pass that eliminates dead code based on those constant
conditions.
This version is also a lot more defensive than the previous code, it will bail
out without doing anything if it finds a code sequence it doesn't understand.
This also makes it easier to implement other similar code optimizations.
Simple time measuring shows no slowdown in the linker, and the size difference for monotouch-test is negligable at best:
256 bytes more for the exectuable:
-rwxr-xr-x 1 rolf staff 72890464 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/monotouchtest
-rwxr-xr-x 1 rolf staff 72890720 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/monotouchtest
3584 bytes less for Xamarin.iOS.dll:
-rw-r--r-- 1 rolf staff 2506240 Dec 1 14:39 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2502656 Dec 1 14:44 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
I don't know why the executable grew slightly, the IL diff for Xamarin.iOS.dll
shows nothing out of the ordinary:
https://gist.github.com/rolfbjarne/33590ad651a21f9a9352ac9b97b9dc06
* [linker] NewRefcount is constantly true for Unified, so trying to inline it is useless.
* [linker] Remove redundant code.
* [linker] Remove nops at the end of methods.
It's not legal IL to have a nop as the last instruction of a method, peverify complains:
> [IL]: Error: [D:\Documentos\Rolf\Xamarin\Xamarin.iOS.dll : AVFoundation.AVAssetImageGenerator::get_AppliesPreferredTrackTransform][offset 0x0000001E] fall through end of the method without returning
so detect and remove nops at the end of methods.
Also add a sanity check to ensure we don't remove nops that are targets for
branch instructions (should never happen, but it doesn't hurt to be safe).
PEVerify shows much fewer errors now, [1721][1] vs [2581][2], although the [IL diff][3]
is bigger (due to the removed nops).
Updated timing measurements show no slowdown in the linker, and the size
difference for monotouch-test is negligable:
32 bytes less for the exectuable:
-rwxr-xr-x 1 rolf staff 72890880 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/monotouchtest*
-rwxr-xr-x 1 rolf staff 72890848 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/monotouchtest*
12288 bytes less for Xamarin.iOS.dll (this is a debug build, a release build
would probably not show any difference at all):
-rw-r--r-- 1 rolf staff 2506240 Jan 12 00:54:49 2018 /Users/rolf/test/old/monotouchtest.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf staff 2493952 Jan 12 00:56:57 2018 /Users/rolf/test/new/monotouchtest.app/Xamarin.iOS.dll
[1]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-new-txt-L1726
[2]: https://gist.github.com/rolfbjarne/9c8fa519a6f8e1718b125472f05ded07#file-peverify-old-txt-L2586
[3]: https://gist.github.com/rolfbjarne/35d5bfec1809ad2a80a7781cebe5b574
Sebastien Pouliot
Rolf Bjarne Kvinge
Vincent Dondain
Jeffrey Stedfast
Alex Soto
Marius Ungureanu
Manuel de la Pena