This is the first step for documenting the error messages in the generator:
create a document for the error messages.
The entries in the document are the same as the ones listed in the error.cs
file (which I've now removed to prevent duplication), with some very minor
editing.
The document is not yet published to the documentation repository (since this
is just the first step).
When using debug simulator we don't generate main.m so we were not passing the gc options.
The MONO_GC_PARAMS variable is not in app.EnvironmentVariables (which only contains environment variables passed to mtouch using --setenv), which is why the above condition does not trigger.
* [Contacts] Fix bug 52571 - Missing API due to binding error
https://bugzilla.xamarin.com/show_bug.cgi?id=52571
Unfortunately [Static] methods inside [Category] lead to bad code
I have exposed alternative methods that call the static extensions
and when XAMCORE_4_0 is a thing they will get inlined in their
respective class
iOS 10 added a new `textFieldDidEndEditing:reason:` to `UITextField`. It
gets called, if set, before the older `textFieldDidEndEditing`.
This cause a problem for code that does add events for both since the
internal `*Delegate` does override both (to allow events) so the call
might be "lost" without additional logic.
This fix makes sure that even using one (or the two) events will work
across all versions of iOS.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=53174
* [Darwin] Fix kqueue/kevent bindings to actually work.
Fix kqueue/kevent bindings to actually work. The P/Invoke signatures were
badly broken (missing an argument), so there's no way this could ever have
worked.
Additionally obsoletes kevent signatures that return bool (they're ignoring
vital information: how many events were actually returned from kevent), and
add overloads that do the right thing.
* [Darwin] Improve input validation and add more tests.
https://bugzilla.xamarin.com/show_bug.cgi?id=52570
In some cases you will find **static** members inside categories like in the following example:
```objc
@interface FooObject (MyFooObjectExtension)
+ (BOOL)boolMethod:(NSRange *)range;
@end
```
This will lead to an **incorrect** Category C# interface definition:
```csharp
[Category]
[BaseType (typeof (FooObject))]
interface FooObject_Extensions {
// Incorrect Interface definition
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
This is incorrect because in order to use the `BoolMethod` extension you need an instance of `FooObject` but you are binding an ObjC **static** extension, this is a side effect due to the fact of how C# extension methods are implemented.
The only way to use the above definitions is by the following ugly code:
```csharp
(null as FooObject).BoolMethod (range);
```
The recommendation to avoid this is to inline the `BoolMethod` definition inside the `FooObject` interface definition itself, this will allow you to call this extension like it is intended `FooObject.BoolMethod (range)`.
```csharp
[BaseType (typeof (NSObject))]
interface FooObject {
[Static]
[Export ("boolMethod:")]
bool BoolMethod (NSRange range);
}
```
We will issue a warning (BI1117) whenever we find a `[Static]` member inside a `[Category]` definition. If you really want to have `[Static]` members inside your `[Category]` definitions you can silence the warning by using `[Category (allowStaticMembers: true)]` or by decorating either your member or `[Category]` interface definition with `[Internal]`.
- Significant changes to target file under msbuild, ImplicitFacade processing in particular
- Tests are disabled due to https://bugzilla.xamarin.com/show_bug.cgi?id=53164 where we can't tests local target files only global
- Requires a mono msbuild with 95ab657a90 for tests to pass
- Until then, this is a workaround:
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Roslyn/System.Reflection.Metadata.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/
* [msbuild] Fixed PathUtils.AbsoluteToRelative() logic
Don't require the 'absolute' path argument to be a FullPath.
The code already calls Path.GetFullPath() on the 'absolute'
path anyway.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53176
* Fixed ResolveSymbolicLinks() to return the input path if realpath() fails
Fixes bug #52758 (https://bugzilla.xamarin.com/show_bug.cgi?id=52758)
For appex the MainAssembly path should be absolute, since mtouch will generate a build-arguments.txt file that then will be used to build the extension in the same mtouch process than the container app. Due to this, if the path stored is relative mtouch won't be able to find the assembly.
* Bump maccore to get fix for launching the simulator for app extensions.
* [runtime] Don't look in shared memory for debug data in normal apps.
Don't look in shared memory for debug data in normal apps, because it
interferes when debugging extensions from the same solution as a container
app:
Example, for a keyboard extension:
1. Run extension in XS.
2. Manually launch the extension's container app (which contains a textbox
that can be used to launch the keyboard).
3. The container app reads the debug data in shared memory which was intented
for the extension, and takes over the debugger.
4. Launch keyboard, which will not be able to connect to the IDE because the
container app already connected to the IDE.
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
Sebastien Pouliot
Timothy Risi
Jeffrey Stedfast
Rolf Bjarne Kvinge
Vlad Brezae
Alex Soto
Chris Hamons
Marek Safar
Emanuel
Vincent Dondain