- https://bugzilla.xamarin.com/show_bug.cgi?id=45298
- Cocoa defaults new NSWindow () to have ReleasedWhenClosed = True but
this is incompatible with our memory management.
- By forcing it to be false during constructors, we prevent this crash.
- Since this is technically a behavior change, I added a static to change
the behavior back.
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
Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret.
Now it's much easier to test new return types (a single line of code), which
avoids a _lot_ of copy-pasting, and makes sure all the different variations
are tested properly.
These new tests found several bugs, which are fixed in subsequent commits.
For Unified, set XAMCORE_2_0, UNIFIED and __UNIFIED__.
For Xamarin.iOS/tvOS/watchOS set both the normal and underscored versions
(IOS and __IOS__, TVOS and __TVOS__, and WATCHOS and __WATCHOS__).
The underscored versions are the public symbols we're setting in the
corresponding projects, so we should use those everywhere to simplify our
code, but due to historical reasons we're still using the other variants in
existing code.
Making sure all the possible variants are set for all projects, makes it
possible to only use the underscored versions in new code.
Also define `GENERATOR` for the generator, so that we can easily share
files between the generator and platform assemblies.
In master's c4b5fa5f we changed how the symlinks in
/Library/Frameworks/Mono.framework/External/xbuild point to the current XI,
which causes problems if master is currently installed into the system, and
then someone runs `install-system` on branch without that change (instead of
installing properly into /Library/Frameworks/Mono.framework/External/xbuild,
`install-system` would modify the files directly in the master checkout's
`_ios-build` directory).
Which would probably work just fine, until some ran `install-system` in the
master checkout, and would now get the MSBuild files from the older branch,
causing obvious confusion and probable headache.
* [msbuild] Remove unused FrameworkList.xmls
* [msbuild] Make files in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS the real deal, not a symlink.
* [msbuild] Make /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS a symlink, instead of each file inside.
* [msbuild] Don't put anything in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1 anymore.
* [msbuild] Remove support for XI/Classic binding projects.
* Improve 'install-system' to clean up old files.
* [msbuild] Simplify XI/Classic targets files a bit.
* [msbuild] Remove dead XI/Classic code.
* Bump maccore to get fix for xamarin-analysis.
commit xamarin/maccore@34c04c2bf1
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Mon Oct 10 16:46:18 2016 +0200
[analysis] Update to put files in /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS.
XI/Classic is being removed now, which means files should go into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS/ instead of into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1.
In 9d4be4c we started building fat applications when building for device in
our test projects. That causes the BuildTestProject to take twice as long,
thus hitting a 5 min timeout value, causing the test to fail.
So change the test to the previous behavior: we were only building test
projects for ARM64 previously, so do that.
The NSUrlSessionHandler is not dealing with 40s correctly, unfortunatly
we are modifying the Authorization header which is a reserved header as
per apple documentation. We need to hide this issue by dealing with the
challenge in the handler.
The fix checks if it is the very first failure of the challenge and we
do have the header, in that case, reject the request and continue with
the handler execution.
Fixes bug https://bugzilla.xamarin.com/show_bug.cgi?id=42936
Remove the IDynamicRegistrar interface, since it's no longer needed (there's
no OldDynamicRegistrar anymore, which means having an interface for a single
type (DynamicRegistrar) is just code bloat at this point).