Log this as an error even if the log file does not exist and/or
is parseable.
Previously, it was possible that if the log file didn't exist
or it was perfectly validly formatted, we would never log that
error code and so it's possible that we wouldn't log *any*
error at all (e.g. empty log file).
Fixes bug #52982: [iOS]Metal samples fail to build with Xcode8.3
(https://bugzilla.xamarin.com/show_bug.cgi?id=52982)
Basically with Xcode8 Apple stopped using an intermediary step to generate the
default.metallib. This was what our `_ForgeMetal` target was doing, generate a `default.metal-ar`
file which was used as input for `_TemperMetal` and then generate the default.metallib.
Instead with Xcode8 you can just give Shaders.air directly to the metallib tool.
The fix in this commit is made in such a way that it still supports Xcode7.
if !Xcode8 then don't change anything.
if Xcode8+ then have `_ForgedMetal` output equal `@(_SmeltedMetal)` (basically skip the _ForgeMetal target).
Xamarin.Mac binding projects would show this error:
> /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.ObjcBinding.CSharp.targets: error : Unknown target framework identifier: Xamarin.Mac.
while at the same time not actually failing the build (so nothing broke,
making it harder to notice).
The error is printed in BTouchTaskBase, which was previously only used for
Xamarin.iOS. Now we're using it for both Xamarin.iOS and Xamarin.Mac (in which
case it's subclassed), so make sure to not validate the
TargetFrameworkIdentifier according to only valid TargetFrameworkIdentifiers
for Xamarin.iOS.
This is accomplished by adding a new virtual overload to validate (and get the
right /target-framework argument for the generator), and override that method
in Xamarin.Mac's BTouch subclass.
* Bump maccore to get partial fix for bug #52710.
Bump maccore to get partial fix for bug #52710 (can't launch/debug today
extensions more than once).
https://bugzilla.xamarin.com/show_bug.cgi?id=52710
* Bump maccore to make the (partial) fix for #52710 work on device as well.
Even if it's in UIKit, this is not a UI type and does not _suffer_ from
the UI thread restriction. In fact it's used with file coordination which
implies threading is required.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=53075
Taken out of our Xcode8 post-mortem: it's easy to forget (while adding)
or miss (while auditing) a `[Async]` attribute on the API that would
benefit from them.
API that are decorated with either:
* [Obsolete] (managed); or
* [Obsoleted] or [Deprecated] (native)
are not to be added *Async methods (or at least be reported as missing)
This also includes updated introspection tests that found the missing *Async API., ensuring that future API addition will immediately notice is an `[Async]` sounds useful.
It was left out by mistake when added (to classic only). Since then macOS
also added support for the API.
references
bugzilla: https://bugzilla.xamarin.com/show_bug.cgi?id=53083
xtro: common.unclassified:!missing-selector! MKLocalSearchRequest::initWithCompletion: not bound
Some of the Clean steps need the _ComputeTargetArchitectures
target to run before they can properly do their thing because
they depend on DeviceSpecific paths.
Also added logic to rm -rf extension *.dSYM and framework *.dSYM
dirs in the container app bin dir (which fails on xbuild due to
a bug in xbuild... yay!)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53007
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
Jeffrey Stedfast
Vincent Dondain
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto