A `[Native]` enum is either 32 bits or 64 bits depending on the CPU,
i.e. it's a `NS[U]Integer`. However the managed representation is
*always* 64 bits, a `long` enum, which means it cannot be used
directly (without a cast) when declaring code that match native.
This also enable us to remove the hack from PR1751 to ignore some
generated trampoline code.
reference:
* https://bugzilla.xamarin.com/show_bug.cgi?id=53058
* generated code diff: https://gist.github.com/spouliot/f6196aa892a7a33257fe2cf421fffc2e
Presently we're looking if enums decorated with [Native] are used, just
like we do for p/invokes and delegate types decorated with a
[MonoNativeFunctionWrapper] attribute.
Testing properly required to add a property to MonoPInvokeCallbackAttribute
so we can get back the type given as it's argument.
* Also check for generics in delegates, ref: #42699
* Ignore failures filed as https://bugzilla.xamarin.com/show_bug.cgi?id=53058
We cannot use generics in native signatures but, with some care (and
generator work), we can still expose nullable on our public delegate API.
AUImplementorStringFromValueCallback is presently the only case of such
an API.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=42699
Apple has both an Empty and Null constants. Our implementation is largely
done in managed code and, for historical reasons [1], match System.Drawing
behaviour. Still the constant is useful for other (e.g. 3rd party) APIs.
Also add CFRect.Infinite for the missing CGRectInfinite symbol.
[1] In the original classic we only provided RectangleF not CGRect
references:
* https://bugzilla.xamarin.com/show_bug.cgi?id=43628
* xtro
common.unclassified:!missing-field! CGRectNull not bound
common.unclassified:!missing-field! CGRectInfinite not bound
IKVM doesn't have API that supports looking for inherited attributes (we'd
have to implement the logic ourselves if we needed it), so I decided to check
if we really need to fetch inherited attributes.
Turns out we don't: removing all lookup for inherited attributes does not
change the generated output, nor does it fail any of our tests.
A few more reasons I think this is fairly safe:
* For events and properties, the `inherits` flag is ignored according to MSDN,
so removing it does not change anything at all.
* Fields can't be inherited (they're not virtual), so asking for inherited
attributes doesn't even make sense.
* Our binding syntax generally does not use inheritance (a base type is
expressed by putting the `[BaseType]` attribute on the binding interface,
not making the binding interface actually inherit from its alleged base
type).
* Even when the syntax does use inheritance (to inline protocols), the inlined
protocols do not use inheritence themselves, so none of the members in the
inlined protocols will override base class member (since there is no base
class).
Generator diff: https://gist.github.com/rolfbjarne/6a767517a9db76e415827039885c6b09 (all changes are unrelated)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52745
Added a new CodesignNativeLibraries task that scans for
and then codesigns each *.dylib and *.metallib in the
app bundle (minus those in the PlugIns and Watch dirs).
The IKVM version won't return an array of the exact attribute type, so casting doesn't work.
Use the generic version instead, which returns an array of the right type
directly, and works with both IKVM and Reflection.
Generator diff: https://gist.github.com/rolfbjarne/06c3ff20dc90631d345aeebd54790018 (all changes unrelated)
'Type.GetType' doesn't work the same with IKVM as with Reflection, so refactor
to code that works the same (and just as correctly) for both IKVM and
Reflection.
In particular there's no need to use 'Type.GetType' with an assembly qualified
typename when we already have the assembly we need to look in: just use the
type's FullName to look up the type in the assembly instead.
Generator diff: https://gist.github.com/rolfbjarne/a3da6c9df53383c4225483f89e16d156
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52860
When the ImageAssets contain an item that doesn't live within
a *.xcassets directory, index into ImageAssets[] rather than
items[] which hasn't been populated yet.
Also fixed the tagsList for-loop to use tagsList.Count instead
for correctness (even though tags.Count and tagsList.Count
should always be identical).
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52851
The problem here is that the .DS_Store file was included in
the .csproj file but did not exist on disk, so when we went
to clone that file into the obj/ dir before running actool
on it, File.Copy() would fail because the file did not
actually exist.
Since these files are worthless anyway, we can safely ignore
them.
Also added logic to verify that files exist before copying
them in order to report a better error than an exception
stack trace.
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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Jeffrey Stedfast
Chris Hamons
Timothy Risi
Alan McGovern