Граф коммитов

202 Коммитов

Автор SHA1 Сообщение Дата
Sebastien Pouliot 05eb96d0a7 Merge branch 'xcode9' into xcode9-master-merge 2017-09-15 11:05:30 -04:00
Manuel de la Pena 809978aa35 [mtouch] Do state why we did not copy the aot (msym) files. (#2594) 2017-09-07 13:14:53 -04:00
Rolf Bjarne Kvinge af44978cce [mtouch] Print verbosity using an invariant culture. Fixes #58849. (#2507)
* [mtouch/mmp] Set CultureInfo.CurrentCulture according to LANG.

This makes it easier to run mtouch/mmp under different locales when testing.

Unfortunately mono checks the system locale before checking LANG, which means
that there's no built-in way in macOS/mono to specify the current locale
without changing the system locale.

* [mtouch] Print verbosity using an invariant culture. Fixes #58849.

https://bugzilla.xamarin.com/show_bug.cgi?id=58849

* [mtouch/mmp] Fix error code.

* [mtouch/mmp] Log/warn when we set the current language.
2017-08-22 09:40:26 +02:00
Rolf Bjarne Kvinge d34918dda2 [mtouch] Report better error (MT4169) when we can't generate a P/Invoke wrapper for a P/Invoke. (#2349) 2017-07-20 15:34:42 +02:00
Rolf Bjarne Kvinge 9042eb87af [docs] Fix according to formatting change. (#2337) 2017-07-18 15:19:23 +02:00
Craig Dunn 27b28b4bf9 [docs] xamarin now requires markdown+yaml (#2258)
* markdown, yaml, api links, accessibility (for images)

ensure iOS docs conform to xamarin docpub standards

* markdown formatting fixes
2017-07-12 21:29:47 -04:00
Rolf Bjarne Kvinge 981af59058 [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes #57966. (#2303)
* [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes #57966.

Also bump maccore to get an mlaunch error for launching a 32-bit app in a 64-bit-only simulator.

https://bugzilla.xamarin.com/show_bug.cgi?id=57966

* [tests][msbuild] Make sure all Info.plists have deployment targets.

Otherwise we get different behavior (32-bit allowed or not) depending on which
Xcode is used to build.

* [mtouch] Default to 64-bit arch if not specified and targeting iOS 11+.

* [tests] Tweak tests to either specify a deployment target < 11 or not build a 32-bit arch.
2017-07-11 08:54:50 +02:00
Rolf Bjarne Kvinge 87e3dbb96f Merge remote-tracking branch 'origin/master' into bindas-registrar-support to fix conflicts. 2017-07-07 17:19:43 +02:00
Rolf Bjarne Kvinge 348df7d196 [docs] Add missing entry about MT2090 errors. (#2297) 2017-07-07 17:17:39 +02:00
Rolf Bjarne Kvinge 11e2f7457b [docs] Add MT4171, and describe MT4169/4170. 2017-07-07 17:13:14 +02:00
Rolf Bjarne Kvinge bdd4e48cfb [linker] Preserve smart enum conversion methods when needed. 2017-07-06 20:27:13 +02:00
Rolf Bjarne Kvinge 7ecbc7abee [registrar] Add support for the BindAs attribute. 2017-07-04 07:35:29 +02:00
Rolf Bjarne Kvinge bc75388fbc [generator] Improve error reporting for api definition that uses the deprecated availability attributes. Fixes #57070. (#2166)
https://bugzilla.xamarin.com/show_bug.cgi?id=57070
2017-06-02 18:31:10 +02:00
Rolf Bjarne Kvinge d17cb6556a [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes #51710 and #54417. (#2162)
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes #51710 and #54417.

* Refactor required symbol collection to store more information about each
  symbol (field, function, Objective-C class), and in general make the code
  more straight forward.
* Implement support for generating source code that references these symbols,
  and do this whenever we can't ask the native linker to keep these symbols
  (when using bitcode). Additionally make it possible to do this manually, so
  that the source code can be generated for non-bitcode platforms too (which
  is useful if the number of symbols is enormous, in which case we might
  surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
  a per-symbol basis. This provides a fallback for users if we get something
  right and we try to preserve something that shouldn't be preserved (for
  instance if it doesn't exist), and the user ends up with unfixable linker
  errors.
* Don't collect Objective-C classes unless they're in an assembly with
  LinkWith attributes. We don't need to preserve Objective-C classes in any
  other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
  code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.

https://bugzilla.xamarin.com/show_bug.cgi?id=54417
https://bugzilla.xamarin.com/show_bug.cgi?id=51710

* [mtouch] Make sure to only keep symbols from the current app when code sharing.

This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
2017-06-02 18:29:19 +02:00
Rolf Bjarne Kvinge c199c9f2c2 [mtouch] Show a nice error (MT4168) if the user registers a managed class with an Objective-C keyword. Fixes #51776. (#2150)
Previously:

    obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:12: error: expected identifier
    @interface register : UITableViewController {
    ^
    obj/iPhone/Ad-Hoc/mtouch-cache/64/registrar.m:4402:21: error: expected unqualified-id
    @interface register : UITableViewController {

    error : Failed to compile the generated registrar code. Please file a bug report at http://bugzilla.xamarin.com

Now:

    error MT4168: Cannot register the type 'register' because its Objective-C name 'register' is an Objective-C keyword. Please use a different name.

https://bugzilla.xamarin.com/show_bug.cgi?id=51776
2017-05-31 19:07:02 +02:00
Chris Hamons 0be72f3c13 [macos] Fix target framework detection issues in mmp (#2096)
- Also detect mismatches between referenced XM.dll and target framework selected
2017-05-30 09:23:28 -05:00
Andi McClure a6cf8c5edc [Do not merge yet] Update to mono 2017-04 branch (#1960)
* Update to mono 2017-04 branch

* Patch from Zoltan to fix build error with CppSharp.CppParser.dll

* Include new linker files in Makefile, based on mareks commit

* [msbuild] Fix running bgen for Xamarin.Mac.

bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.

* System.Data tests should act as if they are running on mobile profile

* Add --runtime=mobile to mono flags in Modern

* Move runtime launcher options up

* System.Data tests should use Mobile profile (mac fix)

* Bump 2017-04 to pick up AOT and assembly resolution fixes

* Build fixes for netstandard.dll and System.Drawing.Primitives.dll

The new handling went in with https://github.com/mono/mono/pull/4501.

I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.

* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS

* Fix 2.1/Facades/netstandard.dll build

* Fix the netstandard targets

* Bump mono to latest 2017-04 commit

* [xharness] Fix adding defines to csproj by correctly detecting existing defines.

* Bump mono to latest 2017-04 commit

* [mtouch] Update csproj with new files.

* [mtouch] Improve reporting for MarkExceptions from the linker.

* Bump mono to latest 2017-04 commit

* Bump mono to pick up latest 2017-04 branch commit (Fixes #55436)

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436

* Add a missing Makefile dependency

* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time

(It is currently being applied for some configurations at runtime only)

* Bump system mono

* Bump mono for assembly loader changes

* Bump system mono

* Update assemblies list as some where moved to facades

6ca5ec442b
c38e4d9220

* Bump mono to latest 2017-04 commit

* Add another new facade

* Bump mono to tip of 2017-04.

* Bump mono to tip of 2017-04.

* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes #56307 and #56308.

System.dll is now completely linked away unless the app actually uses any
System.dll API.

This is the change that caused this to change: 4960d5d2a2

Previously the following types would always be kept by the linker:

```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```

Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).

With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.

I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.

This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.

This means that the fix is to modify these tests accordingly.

https://bugzilla.xamarin.com/show_bug.cgi?id=56307
https://bugzilla.xamarin.com/show_bug.cgi?id=56308

* Bump mono to latest.

* Fix merge conflict that was missed

* [mtouch] Renumber new error which clashes with an existing error number in master.
2017-05-29 18:39:29 +02:00
Rolf Bjarne Kvinge 1548594e7b [mtouch] Allow code sharing assemblies from multiple locations if they're identical. Fixes #56513. (#2119)
* [mtouch] Allow code sharing assemblies from multiple locations if they're identical. Fixes #56498.

We disallow code sharing when the same assembly (based on name) is referenced
from multiple paths, but poke a hole in this logic by allowing the same
assembly from multiple paths when those assemblies are 100% identical, since
that should be 100% safe.

https://bugzilla.xamarin.com/show_bug.cgi?id=56498

* [tests] Comment out assert that asserts due to another bug.
2017-05-25 07:10:56 +02:00
Rolf Bjarne Kvinge 0c87730ff1 [mtouch] Fix linking with the same third-party framework from both extension and container app. Fixes #56635. (#2112)
If both an extension and the container app (or multiple extensions) reference
the same binding assembly for a framework, then we'd error out with an
internal error when trying to copy the framework from both locations to the
container app.

So instead detect when we're trying to copy multiple identical (by comparing
the on-disk contents) frameworks, and only copy one of them.

We'll still show an error if the frameworks are different, but now a nice
MT1035 error with a proper error description instead of an internal error.

https://bugzilla.xamarin.com/show_bug.cgi?id=56635
2017-05-19 17:05:38 +02:00
Sebastien Pouliot 845f365c91 [mmp] Add support for linking only the platform (Xamarin.Mac.dll) assembly on the full profile (#1990)
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.

* Add XM SDK + LinkSkip test

* [macos] Add platform linking support to msbuild

* [macos] Add full SDK test

* [macios] Diable classic from using linkplatform

- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
2017-05-16 18:05:26 -04:00
Chris Hamons 562560d936 Fixup Xamarin.Mac Hybrid AOT and improve testing (#1995)
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
2017-05-16 13:29:08 -05:00
Chris Hamons 18c5e14d98 [macos] Remove linking / registrar restrictions on extensions (#2092)
- [Preserve] on Init is all that is needed now (unsure if additional fixes happened in time since extensions were added)
- https://bugzilla.xamarin.com/show_bug.cgi?id=43197
2017-05-15 13:06:08 -05:00
Rolf Bjarne Kvinge c95034fb2a [mmp] Add support for building to a framework for the embeddinator. 2017-05-09 08:12:39 +02:00
Vincent Dondain 98dd779dd3 [docs] Document XIA0005 float32 rule (#2062) 2017-05-03 16:33:30 -04:00
Rolf Bjarne Kvinge 363eb083ef [docs] Document mmp errors and remove duplicated information about mtouch errors. (#2056) 2017-05-01 14:02:54 -04:00
Rolf Bjarne Kvinge 1eb6c335a6 [mtouch] Disable incremental builds for the simulator. Fixes #55712. (#2054)
It does not make sense to support incremental builds for the simulator (since
no AOT compilation is done), it just makes the test matrix more complicated.

So simplify things by removing support for incremental builds.

We also ignore any (other) --assembly-build-target arguments, because building
to frameworks doesn't make sense either in the simulator.

https://bugzilla.xamarin.com/show_bug.cgi?id=55712
2017-04-28 13:34:37 -04:00
Sebastien Pouliot 8ffb553e9e [linker] Capture and show more information when a MT2001 error occurs (#1947) 2017-03-30 14:41:56 -05:00
Sebastien Pouliot 153056cf7f [mtouch] Provide a more accurate description of the MT0091 error (#1938)
The old one makes it sounds the linker is doing magic ;-)
2017-03-30 07:36:20 -05:00
Vincent Dondain 2302931ceb [doc] Add XIA0004 Missing64BitSupportRule to xamarin-ios-analysis (#1912)
- Also update reference to maccore with the xamarin-analysis bump that includes XIA0004.
2017-03-25 13:02:54 -04:00
Alex Soto 7bc52a12bd [test][introspection] Remove check for void return type on AsyncCandidates test (#1909)
We do support the use of [Async] on methods that do not return void,
we generate an overload with am out parameter to retrieve the returned value

```csharp
[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1)
{
	var tcs = new TaskCompletionSource<bool> ();
	var result = BarString(arg1, (obj_) => {
		if (obj_ != null)
			tcs.SetException (new NSErrorException(obj_));
		else
			tcs.SetResult (true);
	});
	return tcs.Task;
}

[CompilerGenerated]
public unsafe virtual Task BarStringAsync (int arg1, out string result)
{
	var tcs = new TaskCompletionSource<bool> ();
	result = BarString(arg1, (obj_) => {
		if (obj_ != null)
			tcs.SetException (new NSErrorException(obj_));
		else
			tcs.SetResult (true);
	});
	return tcs.Task;
}
```

Modified the introspection test to repor this, updated documentation
and update API definitions reported by introspection.
2017-03-24 11:02:07 -06:00
Rolf Bjarne Kvinge 563f395cac Merge remote-tracking branch 'origin/master' into framework-sdk 2017-03-23 15:33:38 +01:00
Rolf Bjarne Kvinge 8a29f0deae Merge remote-tracking branch 'origin/master' into generator-ikvm 2017-03-22 14:11:00 +01:00
Alex Soto ebcb4ac034 [generator] Fix bug 52573 - Add nowarn and warnaserror to btouch/bmac (#1882)
https://bugzilla.xamarin.com/show_bug.cgi?id=52573

* Added nowarn and warnaserror to btouch/bmac
* Throw a BI0026 if bad args and added error to doc
* Added generator tests
2017-03-22 07:52:24 -05:00
Rolf Bjarne Kvinge 001790ff4e Merge remote-tracking branch 'origin/master' into generator-ikvm 2017-03-16 19:09:33 +01:00
Rolf Bjarne Kvinge 7c8007e4f2 [docs] Add a document for generator error messages. (#1877)
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).
2017-03-16 07:38:56 +01:00
Alex Soto 78052430ab [generator] Fixes bug 52570 - [generator] warn when [Static] is used in a [Category] (#1862)
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]`.
2017-03-14 13:03:13 -06:00
Rolf Bjarne Kvinge 1e498bce22 Merge remote-tracking branch 'origin/master' into framework-sdk 2017-03-07 07:38:30 +01:00
Rolf Bjarne Kvinge 73b3ac0ddc [doc] Document MT0127. (#1782) 2017-02-28 15:53:04 +01:00
Rolf Bjarne Kvinge 83d1111e10 [mtouch] Use fewer error numbers for code sharing failures. 2017-02-28 13:26:42 +01:00
Rolf Bjarne Kvinge d212b97b1a Merge remote-tracking branch 'origin/master' into framework-sdk 2017-02-21 18:14:29 +01:00
Rolf Bjarne Kvinge 0fc9c35f90 [docs] Clearify wording a bit about code sharing occuring once per architecture. 2017-02-20 17:14:14 +01:00
Rolf Bjarne Kvinge cf14456cd5 [mtouch] Add docs and improve MT4146 to be an error if we can detect the generated code won't compile. Fixes #52530. (#1712)
https://bugzilla.xamarin.com/show_bug.cgi?id=52530
2017-02-17 16:00:53 +01:00
Rolf Bjarne Kvinge cdb2e386e4 [docs] Improve code sharing documentation. 2017-02-17 10:17:00 +01:00
Rolf Bjarne Kvinge 07127a76ca [mtouch] Make code sharing failures real warnings. 2017-02-17 10:16:51 +01:00
Rolf Bjarne Kvinge c1f87393ae Merge remote-tracking branch 'origin/master' into framework-sdk 2017-02-17 10:16:41 +01:00
Alex Soto a021c0cd3c [generator] Have WrapAttribute generate virtual members (#1707)
* [generator] Have WrapAttribute generate virtual members

WrapAttribute now has a boolean optional parameter named isVirtual,
this instructs the generator to add the virtual keyword to generated
members.

This is useful when fixing breaking changes so we can keep the wrong
signature generated instead of having manual code files.

* [docs] Add docs about virtual to WrapAttribute
2017-02-16 17:24:40 -06:00
Rolf Bjarne Kvinge 85f28fbd59 [mtouch] Warn if mtouch loads an assembly from a different location than requested.
Warn if mtouch loads an assembly from a different location than requested
(which might be because there are multiple assemblies with the same name).

Also rework the MT0023 check a bit by explicitly loading the root assembly
first, and then detecting if any loaded assemblies matches the root assembly.
This results in code that's a bit more obvious, and it also works correctly
with extensions (previously the entire MT0023 check was skipped for
extensions).
2017-02-10 16:39:15 +01:00
Rolf Bjarne Kvinge e67b9426c8 Document how code sharing between apps and app extensions work. 2017-02-10 16:39:12 +01:00
Rolf Bjarne Kvinge 1f7ce2e445 [mtouch] Fix the error message for 'CompileTask'.
The AOT-compilation occurs in the AOT-task now, and then we compile the result
using CompileTask.

This means that the error message in CompileTask was slightly incorrect, so
rectify it.
2017-02-10 14:46:25 +01:00
Rolf Bjarne Kvinge 024d5a92ca [mtouch] Add target-specific error messages.
This removes a little bit of duplicated code, and gives us slightly better error messages.
2017-02-10 14:46:25 +01:00
Rolf Bjarne Kvinge 5787bc0ef2 [mtouch] Validate the assembly build targets. 2017-02-10 14:29:11 +01:00
Rolf Bjarne Kvinge a590612751 [mtouch] Add an --assembly-build-target option. 2017-02-10 14:29:11 +01:00
Rolf Bjarne Kvinge a07085aafa [mtouch] Create a custom AssemblyCollection class.
Create a custom AssemblyCollection class that contains a dictionary with
assembly identity (name) -> Assembly mapping.

This also means that we can detect if we end up loading multiple assemblies
with the same identity, and show an error in that case (even if that case
should never happen since we cache assemblies based on the identity, it's nice
to have code that ensures it).
2017-02-10 14:15:35 +01:00
Rolf Bjarne Kvinge ce2d9fac32 [docs] Improve MT0099 error help text a little bit. 2017-02-10 14:03:25 +01:00
Alex Soto 3b0f1baf69 [mmp/btouch] Better error when bad xml linker input is given to mmp/mtouch (#1614)
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=52238

If you give mtouch/mmp a linker xml file with bad input for
example a Xamarin.iOS app and the linker.xml has a reference
to Xamarin.Mac instead of X.I.dll i.e.

<?xml version="1.0" encoding="UTF-8" ?>
<linker>
	<assembly fullname="Xamarin.Mac">
    	<type fullname="ObjCRuntime.Constants"/>
	</assembly>
</linker>

You will get a not so helpful generic error

MT2001 Could not link assemblies. Reason: Failed to process XML description: <unspecified>

It seems that when you use a xml file for linker you get a
`XmlResolutionException` from cecil when it fails to resolve
and the better error comes from the inner exception so we use
that instead.

New error output for XmlResolutionException:

MT2017: Could not process XML description: Failed to resolve assembly: 'Xamarin.Mac, Culture=neutral, PublicKeyToken=null'
2017-02-03 14:04:06 -06:00
Rolf Bjarne Kvinge d9c23c2ba8 [mtouch] Automatically enable bitcode if LLVM is enabled. Fixes #52241. (#1620)
Currently we can't build watchOS projects if LLVM is enabled, but bitcode is
not (see bug #51634).

Additionally the IDEs do not have UI to select if bitcode is enabled or not,
so automatically enable it if LLVM is enabled (since most likely people will
be building for the App Store if LLVM is enabled).

https://bugzilla.xamarin.com/show_bug.cgi?id=51634
https://bugzilla.xamarin.com/show_bug.cgi?id=52241
2017-02-03 07:16:17 +01:00
Rolf Bjarne Kvinge e9eb52a78a [docs] Improve MT0091's documentation a little bit. (#1609) 2017-02-01 14:58:54 +01:00
Rolf Bjarne Kvinge 35b17da170 [doc] Add blurb about MT1009. (#1608) 2017-02-01 14:30:45 +01:00
Rolf Bjarne Kvinge bac0253848 [mtouch] Automatically disable incremental builds if building to bitcode and any third-party bindings were found. Works around bug #51710. (#1592)
Most projects building to bitcode (any kind of bitcode, this includes the
marker-only version as well), will fail to link when linking with third-party
libraries and incremental builds are enabled.

So automatically disable incremental builds when we detect this scenario.

This is only a workaround until we can make this scenario build correctly.

https://bugzilla.xamarin.com/show_bug.cgi?id=51710
2017-01-31 14:55:54 +01:00
Rolf Bjarne Kvinge f24c8f7331 [docs] Update text about MT4134 to not mention the legacy registrar anymore. (#1558)
Since the legacy registrar is not available anymore.
2017-01-26 15:31:26 +01:00
Rolf Bjarne Kvinge dae598f96a [docs] Update text about MT5211. Fixes #51772. (#1559)
https://bugzilla.xamarin.com/show_bug.cgi?id=51772
2017-01-26 15:23:47 +01:00
Alex Soto 1799c2f489 [generator] Add BindAs support (#1476)
* [generator] Add BindAs support for NSValue and NSNumber
https://trello.com/c/RYCPEnkh

The intent of BindAs attribute is to have a binding definition as

	[return: BindAs (typeof (bool?))]
	[Export ("boolMethod:")]
	NSNumber BoolMethod (int arg1);

and our generator outputs

	[Export ("boolMethod:")]
	public virtual global::System.Nullable<bool> BoolMethod (int arg1) { ...  }

So we internally do the NSNumber <-> bool conversion, this also
applies to properties, parameters and methods.

* [generator] Fix a small formating issue

* [tests] Add BindAsAttribute generator tests

* [generator] Implement @spouliot's feedback

* [tests] Add BI1048 and BI1049 error tests for [BindAs]

* [generator] Implement Rolf's suggestion to avoid almost all string comparisons in [BindAs] for types

* [generator] Add BindAs support for smart enums and arrays with tests

* [generator] Some code clean up and implementation of PR feedback

* [generator] Add Protocol|Model checks and tests also a NRE check in NSArray creator

BindAs attribute cannot be used in Protocol|Model interfaces

* [generator] Add NSNumber <-> Enum support

* [docs] add BindAs documentation

* [docs] Implement documentation feedback for BindAs
2017-01-25 07:14:55 +01:00
Rolf Bjarne Kvinge 3a480b53bf Merge pull request #1506 from rolfbjarne/mtouch-single-invocation
[mtouch] Build extensions and the container app in the same mtouch process.
2017-01-16 18:33:42 +01:00
Sebastien Pouliot a563a66c34 [linker] Update BaseSubStep subclasses to use ExceptionalSubStep (#1507)
This allows mtouch to give better error message when something unexpected
occurs in the linker pipeline (at least for the sub-steps).

Practically it means fewer, contextless MT2001 errors. The replacements
error code are more precise, e.g.
* what was being done;
* what was being processed

and helps both diagnosing and, possibly, gives clues for workarounds
2017-01-16 11:42:41 -05:00
Rolf Bjarne Kvinge 53fc697aad [mtouch] Refactor command-line parsing to be reusable.
Also add a few tests to verify how we treat the root assembly (or lack
thereof).
2017-01-16 13:52:37 +01:00
Vincent Dondain ded6d2f129 [mtouch] Update MT0091 message (#1453)
Fixes bug #40835: Improve enable managed linker error message
(https://bugzilla.xamarin.com/show_bug.cgi?id=40835)
2017-01-09 16:34:58 +01:00
Vincent Dondain 10d7858c4f [docs] Fix binding_types_reference_guide typo 2017-01-04 15:58:49 +01:00
Rolf Bjarne Kvinge ab21da1b85 [xharness] Add support for uninstalling apps from device. (#1413)
The new error message / number is used in mlaunch.
2017-01-02 08:58:46 +01:00
Rolf Bjarne Kvinge ab2548a115 [mtouch] Automatically create the output directory if it doesn't exist. (#1414) 2016-12-24 10:57:08 -05:00
Vincent Dondain 064a747de3 [Doc] Introduce xamarin-analysis-doc-tool (#1374)
* [Doc] Introduce xamarin-analysis-doc-tool

This tool is responsible of producing the xamarin-analysis.md file which is
our Xamarin.Analysis rules documentation.

It will always override the content of the previous xamarin-analysis.md file.

We generate the documentation based on the existing rules in xamarin-analysis/shared/Xamarin.Analysis/Xamarin.iOS.Analysis.targets
2016-12-22 15:06:35 -05:00
Vincent Dondain 6f7c5f77d0 [binding_types_reference_guide] Fix minor typo 2016-12-19 15:25:02 -05:00
Vincent Dondain 887a410fe2 [msbuild] Add error codes for PropertyListEditorTaskBase (#1325)
* [msbuild] Add error codes for PropertyListEditorTaskBase

* [msbuild] Add task names in all errors' descriptions
2016-12-12 10:30:42 +01:00
Rolf Bjarne Kvinge 7842a0b506 [mtouch] Remove deprecated Classic commmand-line arguments. (#1319)
* [mtouch] Remove deprecated Classic commmand-line arguments.

* [mtouch docs] Document MT0022's death.
2016-12-08 18:59:04 +01:00
Vincent Dondain 901b94d6e1 Merge pull request #1237 from VincentDondain/msbuild-mt-errors
[msbuild] Add msbuild error code logic
2016-12-08 12:50:58 -05:00
Vincent Dondain 3d0e140f3c [xi-errors] Add headers for error code ranges 2016-12-07 16:33:34 -05:00
Alex Soto feac0d2315 [Foundation] Adds single object notifications to Notifications class (#1075)
Trello: https://trello.com/c/mKsUDti8

This adds a new overload to our Notifications class

Current:

public static NSObject ObserveDidStart (EventHandler<NSNotificationEventArgs> handler)

New overload:

public static NSObject ObserveDidStart (NSObject objectToObserve, EventHandler<NSNotificationEventArgs> handler)

This allows our users to have single object subscription to our
easy to find notifications.

Also this commit adds an Advice attribute encouraging to use the
Notifications class instead of the NSString based notifications
2016-11-28 10:19:21 -06:00
Vincent Dondain 8ea1509dec [msbuild] Add msbuild error code logic
- `LoggingExtensions` has a new `MTError` extension method that helps generate
  an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
2016-11-24 15:24:30 +01:00
Sebastien Pouliot c92934eb6d [mtouch][mmp] Only allow `appletls` for the TLS provider (#1132)
The old `legacy` option will now be reported as a warning. 

That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE). 

This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls

Note: The BCL changes will happen in later stages.
2016-11-08 14:42:40 -05:00
Rolf Bjarne Kvinge d42a9f4909 [mtouch] Make MT2015 (invalid HttpMessageHandler) a warning for known http message handlers on watchOS. Fixes #46552. (#1134)
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.

So make it a warning instead (and document what the user has to do to fix the
warning).

https://bugzilla.xamarin.com/show_bug.cgi?id=46552
2016-11-08 11:13:53 -05:00
Rolf Bjarne Kvinge 7728c4cd19 [registrar] Use metadata tokens instead of strings to find types and methods. (#1085)
Use metadata tokens instead of strings to find types and methods.

This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.

Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).

|                |    Before     |     After     |       Diff        |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit |  102.810.144  |  102.609.456  | -200.688 = -0,20% |
| dontlink/64bit |  107.420.576  |  107.221.792  | -198.784 = -0,19% |
| linksdk/32bit  |   40.957.296  |   40.936.864  |  -20.432 = -0,05% |
| linksdk/64bit  |   43.113.136  |   43.093.936  |  -19.200 = -0,04% |
| linkall/32bit  |   38.410.032  |   38.348.288  |  -61.744 = -0,16% |
| linkall/64bit  |   40.315.200  |   40.267.344  |  -47.856 = -0,12% |

Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.

This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.

For a non-linked test app I get the following using the Xamarin profiler:

|                   |  Before |  After  |       Diff      |
|-------------------|--------:|--------:|----------------:|
| Memory allocated  |  2,8 MB |  2,4 MB | -0,4 MB = -14 % |
| Objects allocated |   43678 |   38463 |   -5215 = -12 % |
| Private bytes     | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set       | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
2016-11-01 14:34:56 -04:00
Sebastien Pouliot 7b38187479 [mtouch][mmp] Unify user resources removal as a link step (#1026)
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.

The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.

E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites

mtouch (before)
		Total time: 64202 ms

mtouch (after)
		Total time: 34840 ms

* Add XM support for RemoveUserResourcesSubStep

* Tests supplied by @chamons
2016-11-01 13:11:25 -04:00
Rolf Bjarne Kvinge 4371ea4540 [static registrar] Fix registration of generic types. Fixes #44926. (#1063)
https://bugzilla.xamarin.com/show_bug.cgi?id=44926
2016-10-28 18:42:45 +02:00
Rolf Bjarne Kvinge dde242c32a Allow using LinkWith attribute without a native library. (#997)
This makes it possible to set linker flags per assembly:

    [assembly: LinkWith (LinkerFlags = "-lsqlite3")]

Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).

Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
2016-10-28 10:50:42 -04:00
Rolf Bjarne Kvinge f6d7ddb9f1 [docs] Remove mention of old Xamarin.iOS version. (#1059)
There's no need to mention that something was introduced in Xamarin.iOS 5.2.
2016-10-28 10:11:50 -04:00
Rolf Bjarne Kvinge 7e3cdb35f4 [docs] Document that the LinkWith.LinkTarget property is ignored. (#1060) 2016-10-28 10:11:42 -04:00
Rolf Bjarne Kvinge a1644f6e13 [registrar] Improve an error message. (#1047) 2016-10-28 08:38:38 -04:00
Rolf Bjarne Kvinge d1df84e01e [docs] Show bugzilla links (and to the right product) whenever it makes sense. (#1048) 2016-10-28 08:37:16 -04:00
Rolf Bjarne Kvinge 9d85ca79ab Unify stret detection between the generator and platform assemblies, and fix stret detection on watchOS. Fixes #44709.
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
2016-10-13 17:35:51 +02:00
Rolf Bjarne Kvinge 0863e412b4 Remove XI/Classic support (#926)
* [tests] Remove Classic SDK tests.

* Remove XI/Classic support.

This also means we can remove support for the legacy registrars.

* [monotouch-test] Remove legacy registrar tests.

* [tests/mtouch] Remove Classic tests (and legacy registrar logic).

* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
2016-09-30 15:02:17 -04:00
Sebastien Pouliot 5b80e7f85c [mtouch][linker] Provide a more specific error code when OptimizeGeneratedCodeSubStep fails (#903)
The MT2001 error is a general, something went bad, in the linker code
base. The stack trace is often enough to track down issues but in some
cases it would be easier to ask customers for a specific assembly
(rather than their complete project) to investigate an issue.

Example:

error MT2103: Binding Optimizer failed processing `System.Void GoogleConversionTracking.Unified.GoogleConversionPing::.ctor()`.
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
  at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessIsDirectBinding (Mono.Cecil.MethodDefinition caller, Mono.Cecil.Cil.Instruction ins) [0x00026] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:264
  at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessCalls (Mono.Cecil.MethodDefinition caller, Int32 i) [0x00337] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:197
  at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.Process (Mono.Cecil.MethodDefinition method) [0x0007b] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:81
  at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00004] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:48
---
  at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00014] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:50
  at Mono.Tuner.SubStepDispatcher.DispatchMethod (Mono.Cecil.MethodDefinition method) [0x0001d] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:215
  at Mono.Tuner.SubStepDispatcher.BrowseMethods (ICollection methods) [0x0001c] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:167
  at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) [0x0006b] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:145
  at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) [0x00050] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:123
  at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) [0x0000f] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:104
  at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00027] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/linker/Mono.Linker/Pipeline.cs:118
  at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) [0x000ac] in /Users/poupou/git/xamarin/xamarin-macios/tools/mtouch/Tuning.cs:79

Right now the MT2001 would only include the inner exception, which does
not include any clue to which assembly caused the exception.

Note: The same pattern to be applied to other BaseSubStep subclasses in
separate commits.

Related to (but not the fix for) https://bugzilla.xamarin.com/show_bug.cgi?id=44701
2016-09-28 11:46:14 -04:00
Alex Soto ff326bdfdb [generator] ForcedType is now only valid on parameters, properties and return value
https://bugzilla.xamarin.com/show_bug.cgi?id=37175
https://bugzilla.xamarin.com/show_bug.cgi?id=44322

* ForcedType is now only valid on parameters, properties and return value
* Added generator test
* Fixed bindings accordingly
* Fixed docs
2016-09-26 03:57:57 -05:00
Alex Soto bcbe813ab1 [generator] Fix bug 37175 and bug 44322
https://bugzilla.xamarin.com/show_bug.cgi?id=37175
https://bugzilla.xamarin.com/show_bug.cgi?id=44322

Sometimes iOS API is returning objects of the wrong type for example

- (NSURLSessionDownloadTask *)downloadTaskWithRequest:(NSURLRequest *)request

It clearly states that it will return an NSURLSessionDownloadTask
instance, but yet it returns a NSURLSessionTask and we throw an
InvalidCastException when creating the managed object. This is
fine in ObjC but for us in a type-safety context is not.

Introducing ForcedTypeAttribute when applying this attribute
we will use GetINativeObject instead of GetNSObject which
the former does not perfom a type check on the underlying object
2016-09-23 17:53:22 -05:00
Rolf Bjarne Kvinge 88a9b809d2 CFNetworkHandler is not a valid http message handler for watchOS, so show a helpful message if someone tries. (#879) 2016-09-22 18:08:16 +02:00
Rolf Bjarne Kvinge d4edc453a6 Fix default http message handler for watchOS. (#873)
* Fix default http message handler for watchOS.

Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).

* [tests] Remove explicit http client handler from project files.

Just use the default instead, since the set of valid http client handlers varies between platforms.
2016-09-22 14:29:18 +02:00
Rolf Bjarne Kvinge 7e3cc1f376 [mtouch-errors] Suggest disabling incremental builds to work around MT3001. (#872) 2016-09-22 10:37:02 +02:00
Sebastien Pouliot eaf2ef6688 [generator] Add more control over generated enums/fields (#836)
This allows us to convert some existing manual conversion code into
generated code and never miss a new constant being added [1].

The additional control comes in two forms:

* allow [Field (null)]: a null NSString constant will return this
  enum value instead of throwing an ArgumentNullException;

* a new `[DefaultEnumValue]` attribute allow marking the constant to be
  returned if the enum value is not known;

[1] Vincent found some missing in HomeKit when adding the new ones
from iOS 10.

This commits also adds documentation for the existing (missing) and
new attributes.
2016-09-15 11:35:03 -04:00
Alex Soto e397849108 [generator] Fix bug 43579 - Generator emits invalid code when using the same method name (overload) in @delegates using events and C# delegates (#817)
* [generator] Fix bug 43579 - Generator emits invalid code when using the same method name (overload) in @delegates using events and C# delegates
https://bugzilla.xamarin.com/show_bug.cgi?id=43579

Bug Description:
Generator will emit invalid code when using the same name (overload)
in a method inside a @delegate (protocol) that is decorated
either with EventArgs or DelegateName

-----------------------------------------------------------------

This commit introduces a new attribute named DelegateApiNameAttribute
which mimics the EventNameAttribute but for delegate properties in
host classes

It is used to specify the delegate property name that will be created when
the generator creates the delegate property on the host
class that holds events and delegates.

This is really useful when you have two overload methods that makes
sense to keep them named as is but you want to expose them in the host class
with a better given name.

example:
 interface SomeDelegate {
     [Export ("foo"), DelegateApiName ("Confirmation"), DelegateName ("Func<bool>"), DefaultValue (false)]
     bool Confirm (Some source);
 }

 Generates propety in the host class:
	Func<bool> Confirmation { get; set; }

This also introduces two new BIXXXX errors:
- BI1043 Repeated overload {mi.Name} and no [DelegateApiNameAttribute]
provided to generate property name on host class.
- BI1044 Repeated name '{apiName.Name}' provided in [DelegateApiNameAttribute].

Which provides an error instead of generating invalid C# code.

Generator test included :D

* [docs] Added DelegateApiNameAttribute and IgnoredInDelegateAttribute docs

Also added Protocol where Model was used in our docs so we do not
misslead customers about it
2016-09-14 08:20:08 -04:00
Rolf Bjarne Kvinge b789deaf8e [mtouch] Require deployment target to be 8+ for incremental builds. (#805)
This is something that changed with 70f1346b: our libxamarin.dylib now
requires iOS 8+, which means the app itself must require iOS 8+ when using
libxamarin.dylib.

This fixes an msbuild failure (Xamarin.iOS.Tasks.IBToolLinking("iPhone").BuildTest):

    Process exited with code 1, command:
    /Applications/Xcode73.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang  -framework Foundation -framework UIKit /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libmonosgen-2.0.dylib /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphoneos.sdk/usr/lib/libxamarin-debug.dylib -lz -isysroot /Applications/Xcode73.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS9.3.sdk -Qunused-arguments -miphoneos-version-min=7.0 -arch armv7 -shared -read_only_relocs suppress -install_name @executable_path/libXamarin.iOS.dll.dylib -fapplication-extension -o /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.dylib -x assembler /Users/builder/data/lanes/1381/5f73edaa/source/xamarin-macios/msbuild/tests/MyIBToolLinkTest/obj/iPhone/Debug/mtouch-cache/Xamarin.iOS.dll.armv7.s -DDEBUG
    ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
    ld: embedded dylibs/frameworks are only supported on iOS 8.0 and later (@executable_path/libxamarin-debug.dylib) for architecture armv7
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
2016-09-08 15:01:48 +02:00
Rolf Bjarne Kvinge 7a34f5e9bf [mtouch] Fix incremental builds when generating P/Invoke wrappers. Fixes #44048. (#788)
We need to compile the generated P/Invoke wrappers to a dylib, and link the
dylib for the product assembly (Xamarin.WatchOS.dll) with the generated
P/Invoke wrappers.

Since there might be P/Invokes in any assembly, just link in the P/Invoke
wrapper dylib for every assembly.

https://bugzilla.xamarin.com/show_bug.cgi?id=44048
2016-09-07 17:22:34 +02:00
Manuel de la Pena 4de097effa [mtouch] Better error handling when copying the aot files. (#720) 2016-08-31 08:18:41 -04:00
Sebastien Pouliot 09ca512a79 [docs][mtouch] Add more details for handling MT0000 and fix typo for MT0091 (wrong number shown) (#633) 2016-08-19 08:25:31 -05:00
Sebastien Pouliot 69c526395e [docs] Ease tracking updates to code that requires change to the web site documentation (#573)
This makes it possible to have a single PR with both the feature and the
documentation changes.
2016-08-08 17:07:59 -04:00