The latest NSUrlSessionHandler implementation switched from loading the
request into memory (NSData) to loading it from a stream (NSInputStream).
The later is more efficient, at least for large POST'ed requests which
could, in theory, not even fit in memory.
Now using a stream means a different API is used. NSMutableUrlRequest
Body and BodyStream properties are exclusive but also a bit different as
the later won't set Content-Length [1] and switch to chunked encoding [2]
Even if the current code is compliant with HTTP/1.1 this breaks some
common POST/PUT usage that worked "as expected" in the previous (C8)
release.
To fix this we ask for the stream's length. We assume that if the length
is known then it's (likely) already (or fitting) in memory and use the
(old, in memory) Body property, which will set Content-Length.
If the length is unknown then we use the BodyStream approach so large
POST will continue to work (well over past/C8 limits).
Finally there might be case where developers will prefer to avoid the
extra memory (of `Body`) so a new property `MaxInputInMemory` is added
to set a maximum. It defaults to `Int64.MaxValue` so `Body` will be
used whenever possible. It can be set to `0` to get back the original C9
(always use a stream) behavior.
references:
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=52682
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=52711
[3] https://devforums.apple.com/message/919330#919330
- Update comments on XM45.targets file
- Remove unnecessary AssemblySearchPaths hack causing issues using nugets with same name as Facades
- Note: MSBuild with XM 4.5 is still broken for now
* Move NSTouch ctor to code-behind and obsolete
* Remove XAMCORE_4_0 check for NSTouch DisableDefaultCtor
* Add NSTouch.cs to frameworks.sources
* Skip NSSpellCheckerCanidates in typo test
* Add helper properties for the PrintCore methods that return the correct types instead of IntPtrs
* NSPrintInfo make bindings internal and change manual properties to getter methods
https://bugzilla.xamarin.com/show_bug.cgi?id=52501
Cycle 9 (10.4) is now out and I'm fairly certain we'll see Xcode8.3 out
in March, so that will become 10.6 (once stable), making our `15.1`
target to be 10.8, again when stable.
XM is not affected as it gets the API updates on the next cycle/train.
* [tests][generator] Port XI/Classic tests to XI/Unified.
* [tests][generator] Comment out code triggering previously unknown bugs.
These tests makes the generator fail:
error BI0000: 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 Generator.GetSetterExportAttribute (System.Reflection.PropertyInfo pinfo) [0x0002e] in /work/maccore/master/xamarin-macios/src/generator.cs:1981
at Generator.Go () [0x007e3] in /work/maccore/master/xamarin-macios/src/generator.cs:2162
at BindingTouch.Main2 (System.String[] args) [0x010b2] in /work/maccore/master/xamarin-macios/src/btouch.cs:435
at BindingTouch.Main (System.String[] args) [0x0001d] in /work/maccore/master/xamarin-macios/src/btouch.cs:77
at System.Environment.get_StackTrace () [0x00000] in /work/maccore/master/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/corlib/System/Environment.cs:321
at ErrorHelper.ShowInternal (System.Exception e) [0x000dc] in /work/maccore/master/xamarin-macios/src/error.cs:200
at ErrorHelper.Show (System.Exception e) [0x00027] in /work/maccore/master/xamarin-macios/src/error.cs:151
at BindingTouch.Main (System.String[] args) [0x0002b] in /work/maccore/master/xamarin-macios/src/btouch.cs:79
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52664.
* [tests][generator] Comment out code triggering previously unknown bugs.
This has been filed as https://bugzilla.xamarin.com/show_bug.cgi?id=52665.
Properly determine if selectors are inlined by not deciding anything until we
have the information required to make a correct decision. Since we're now
determining the target platform using the command-line argument, we can't use
the corresponding variables until after the command-line arguments have been
parsed.
This fixes several generator tests when those tests are built using XI/Unified
(so new new tests are needed for this).
https://bugzilla.xamarin.com/show_bug.cgi?id=52646
Don't generate calls to [UIApplication|NSApplication].[EnsureEventAndDelegateA
reNotMismatched|EnsureDelegateAssignIsNotOverwritingInternalDelegate] from
third-party binding code, since those methods are internal.
This fixes the bug24078-ignore-methods-events test when run using XI/Unified.
Fixes this warning:
Makefile:163: warning: overriding commands for target `virtualwrap'
Makefile:40: warning: ignoring old commands for target `virtualwrap'
Clang's static analyzer tought me something new today: 'copy' properties are
not automatically deallocated 😒:
monotouch-debug.m:237:1: warning: 'XamarinHttpConnection' lacks a 'dealloc' instance method but must release '_completion_handler' and others
@implementation XamarinHttpConnection
^
This warning:
shared.m:216:3: warning: Incorrect decrement of the reference count of an object that is not owned at this point by the caller
[pool release];
^~~~~~~~~~~~~~
is somewhat incorrect, because we're using NSAutoreleasePools in uncommon ways
(at the same time it's not entirely incorrect either, because we're not
following Apple's documentation about how to use NSAutoreleasePools).
Luckily calling [NSAutoreleasePool drain] is equivalent to [NSAutoreleasePool
release], so just replace the latter with the former to silence the warning,
since clang doesn't know those two are equivalent.
At the beginning of dawn, not long after the big bang, we used to vibrate the
phone if there was a problem when connecting to the debugger in the IDE, and
the number of times the phone vibrated indicated a certain error condition.
This innovative debugging technique was at some point replaced with more
intuitive (albeit less innovative) error reporting, however the *_connect_*
family of functions continued returning the number of times the phone should
vibrate, even if the caller was now soundlessly ignoring this information.
After many years someone had the wonderful idea of running a static analyzer
on the code, and now the unused return value is not so silent anymore:
monotouch-debug.m:663:5: warning: Value stored to 'rv' is never read
rv = monotouch_connect_usb ();
^ ~~~~~~~~~~~~~~~~~~~~~~~~
monotouch-debug.m:665:5: warning: Value stored to 'rv' is never read
rv = monotouch_connect_wifi (hosts);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
monotouch-debug.m:667:5: warning: Value stored to 'rv' is never read
rv = xamarin_connect_http (hosts);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So fix the warning by removing the return value.
This fixes an issue clang's static analyzer found: if an exception occured in
a call to managed code, we wouldn't process the list of objects to dispose:
trampolines-invoke.m:549:2: warning: Potential leak of memory pointed to by 'dispose_list'
MONO_THREAD_DETACH; // COOP: This will switch to GC_SAFE
^~~~~~~~~~~~~~~~~~
./xamarin/runtime.h:306:11: note: expanded from macro 'MONO_THREAD_DETACH'
} while (0)
^
Fix this by always processing the list of objects to dispose, even if
exceptions occur.
trampolines.m:75:22: warning: Result of 'malloc' is converted to a pointer of type 'id', which is incompatible with sizeof operand type 'void *'
id *buf = (id *) malloc (sizeof (void *) * length);
~~~~ ^~~~~~ ~~~~~~~~~~~~~~~
trampolines-i386.m:126:19: warning: Assigned value is garbage or undefined
it->state->edx = v[1];
^ ~~~~
trampolines-x86_64.m:410:16: warning: Assigned value is garbage or undefined
*reg_ptr = v [stores];
^ ~~~~~~~~~~
trampolines-x86_64.m:447:14: warning: Assigned value is garbage or undefined
*reg_ptr = v [stores++];
^ ~~~~~~~~~~~~
Getting a time zone instance in two different code paths, one allocating the
time zone instance, and the other not allocating, is problematic when we're
unconditionally freeing the time zone at the end.
xamarin-support.m:58:2: warning: Incorrect decrement of the reference count of an object that is not owned at this point by the caller
[tz release];
^~~~~~~~~~~~
So fix this by autoreleasing the allocated timezone.
Fix detection of fat executable to only return true if we have both a 32-bit
and a 64-bit architecture (which is what the `IntPtrSizeOptimization` test
needs to know), and not more than one architectures (since that can be
`armv7`+`armv7s`, i.e. two 32-bit architectures).
mcs will miscompile using statements that has a catch clause that returns
early (by using 'return;') and a finally clause with await (the using's
variable won't be disposed).
So refactor a little bit to avoid returning early from inside a using
statement.
Comparing pmcs-processed/generatedo code is redundant, because we're already
comparing the original code. Also the filenames aren't stable (they change
every time pmcs is executed), which makes any diff contain unwanted noise.
The `CFStreamEventType` enum is based on `NSUInteger`. The native delegate
CallbackDelegate was using it directly and that made it incorrect on 32
bits platforms.
We have introspection tests to check enums on p/invoke, but it seems they
don't cover native delegates - decorated with [MonoNativeFunctionWrapper]
That's to be added in a different PR.
references:
https://bugzilla.xamarin.com/show_bug.cgi?id=52279
* [tests][intro] Validate signatures of delegates decorated with [MonoNativeFunctionWrapper]
This cuts down another group of conditional compilation sections, paving the
way for an IKVM-based generator.
This makes it required to pass --target-framework for to generator executables
(previously only required for Xamarin.Mac/Unified to distinguish between the
different Xamarin.Mac/Unified variants), but it should be invisible to users
since we'll automatically pass the correct --target-framework argument from
the corresponding scripts (btouch/btv/bwatch/bmac) and the MSBuild targets.
This will only break somebody who is executing the managed executables
directly, but nobody should do that in the first place (it's not a supported
scenario).
Generated diff: https://gist.github.com/rolfbjarne/1674be6625632446dba774a305951981
Sebastien Pouliot
Chris Hamons
Rolf Bjarne Kvinge
Timothy Risi
Alan McGovern