The simulators now have an updated libsqlite3.dylib, so this test needs to be
updated accordingly.
This fixes a link sdk test failure:
[FAIL] DllImportTest.Sqlite3 : sqlite3_key
* [monotouch-test] Disable EmptyNib tests due to Xcode9 no longer builds nibs if deployment target < 7.0
EmptyNib.xib : ibtool error : Compiling IB documents for earlier than iOS 7 is no longer supported.
* [monotouch-test] Fixt CalendarTest.TestEnumerateDates
It seems that NSCalendar.CurrentCalendar.EnumerateDatesStartingAfterDate
won't stop enumerating unless `stop` is set to `true`.
* [Tests] Add CheckXcodeVersion support for Xcode 9
* [introspection] Avoid introspection to crash with Xcode 9 Beta 1
* [monotouch-test] bring back LogicalName removal from monotouch-test.csproj
* [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=54417https://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.
* [registrar] Detect more invalid characters in selectors so that we can report better errors. Fixes#55568.
https://bugzilla.xamarin.com/show_bug.cgi?id=55568
* [mtouch] Add a few comments about duplicated data between mtouch and tests.
In 11390f119c we stopped setting the force flag
when the cache was invalid, because we'd delete the cache anyway, and it was
determined that deleting the cache was enough.
Unfortunately it's not, because some output is not in the cache, and might not
get correctly updated.
Scenario:
* User builds app.
* User changes some build option (for instance switching off incremental
builds).
* User does an insignificant change in a source file for the executable
process.
* User builds app again (without cleaning). This will rebuild the exe, but
since the change was insignificant, all the IL, except the MVID, would
remain identical.
* mtouch would see that the command-line options changed, and invalidate the
cache. This would delete the cache, and everything would be rebuilt,
including AOT-compiling the assemblies again.
* When the time came for mtouch to copy assemblies to the app directory,
mtouch would realize that the existing .exe in the app (which was not
deleted because it's not in the cache, but the actual output directory) was
only insignificantly different (only the MVID was different, which our cache
logic knows to ignore when comparing assemblies), so it wouldn't copy the
.exe to the .app.
* At runtime we'd assert, because the MVID in the aot-compiled code was
different from the MVID in the assembly:
error: Failed to load AOT module '(null)' while running in aot-only mode: doesn't match assembly.
* The exact assert varies depending on which build option changed. Other
variations:
Failed to load AOT module '(null)' while running in aot-only mode: compiled against GC (4, while the current runtime uses GC sgen)
* Assertion at /Users/builder/data/lanes/4691/0719ced1/source/xamarin-macios/external/mono/mono/metadata/metadata.c:1118, condition `idx < t->rows' not met
Because of this I'm reverting 11390f119c, and
once again setting the force flag when the cache is invalid. It might be
overkill, but it's the safest option (cache invalidation is after all the only
hard problem in computer science), and bugs are very annoying and
timeconsuming to track down.
https://bugzilla.xamarin.com/show_bug.cgi?id=54973
When converting strings to a sequence of bytes, we can't just cast chars to
ints, and write that, because non-ascii characters will resulting values
outside the byte range.
Instead explicitly convert the string to a UTF8 byte array, and process that.
https://bugzilla.xamarin.com/show_bug.cgi?id=56876
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
* 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
6ca5ec442bc38e4d9220
* 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=56307https://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.
* [registrar] Add support for specifying that a protocol changed informal status in a certain SDK. Fixes#43780
Add support for specifying that an informal protocol became a formal protocol
(or the reverse) in a certain SDK version, so that the static registrar can
generate the correct code based on the SDK being built with.
This also fixes a series of compiler warnings when using the static registrar:
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:374:11: warning: duplicate protocol definition of 'CALayerDelegate' is ignored
@protocol CALayerDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/QuartzCore.framework/Headers/CALayer.h:798:11: note: previous definition is here
@protocol CALayerDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:824:11: warning: duplicate protocol definition of 'WebDownloadDelegate' is ignored
@protocol WebDownloadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebDownload.h:60:11: note: previous definition is here
@protocol WebDownloadDelegate <NSURLDownloadDelegate>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:851:11: warning: duplicate protocol definition of 'WebFrameLoadDelegate' is ignored
@protocol WebFrameLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebFrameLoadDelegate.h:51:11: note: previous definition is here
@protocol WebFrameLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:866:11: warning: duplicate protocol definition of 'WebPolicyDelegate' is ignored
@protocol WebPolicyDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebPolicyDelegate.h:138:11: note: previous definition is here
@protocol WebPolicyDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:869:11: warning: duplicate protocol definition of 'WebResourceLoadDelegate' is ignored
@protocol WebResourceLoadDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebResourceLoadDelegate.h:46:11: note: previous definition is here
@protocol WebResourceLoadDelegate <NSObject>
^
In file included from Xamarin.Mac.registrar.full.i386.m:1:
./Xamarin.Mac.registrar.full.i386.h:872:11: warning: duplicate protocol definition of 'WebUIDelegate' is ignored
@protocol WebUIDelegate
^
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/WebKit.framework/Headers/WebUIDelegate.h:153:11: note: previous definition is here
@protocol WebUIDelegate <NSObject>
^
https://bugzilla.xamarin.com/show_bug.cgi?id=43780
* [registrar] Use a string to specify when a protocol went from informal to formal.
Use a string to specify when a protocol went from informal to formal, and
don't support the reverse condition (going from formal to informal), since
it's currently not needed and makes the code more complicated and harder to
understand.
Also add an mtouch test, and update an existing mmp test to be more restrictive.
* [registrar] Rename from 'InformalUntil' to 'FormalSince'.
It just sounds better.
* [generator] Keep [NotImplemented] info so it is usable in 3rd party bindings. Fixes bug 52664
https://bugzilla.xamarin.com/show_bug.cgi?id=52664
Currently we do not keep the [NotImplemented](0) information and the
generator gets a little confused because it will not find an Export
inside the getters/setters of properties and there is no way to tell
if this was intentional or not. We now keep the [NotImplemented]
and also add some null checks in the generator where needed.
Reenabled tests disabled in 9f036b218a
[0]: https://developer.xamarin.com/guides/cross-platform/macios/binding/objective-c-libraries/#Objective-C_Mutable_Pattern_and_Properties
* [generator] Implement feedback
* Added quote method
* Teach linker about NotImplementedAttribute
* [generator] Improve Quote method
* [generator] Fix quote now for realsssss
Rework how the two different xammac configurations are done, so that we don't
generate identical makefile targets for both variations (we'll generate a
single makefile target, and the configuration is selected using an environment
variable).
Fixes these makefile warnings:
Makefile-mac.inc:303: warning: overriding commands for target `build-mac-unified-xammac_tests'
Makefile-mac.inc:287: warning: ignoring old commands for target `build-mac-unified-xammac_tests'
Makefile-mac.inc:307: warning: overriding commands for target `clean-mac-unified-xammac_tests'
Makefile-mac.inc:291: warning: ignoring old commands for target `clean-mac-unified-xammac_tests'
Makefile-mac.inc:310: warning: overriding commands for target `exec-mac-unified-xammac_tests'
Makefile-mac.inc:294: warning: ignoring old commands for target `exec-mac-unified-xammac_tests'
Makefile-mac.inc:313: warning: overriding commands for target `run-mac-unified-xammac_tests'
Makefile-mac.inc:297: warning: ignoring old commands for target `run-mac-unified-xammac_tests'
https://bugzilla.xamarin.com/show_bug.cgi?id=56492
* [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.
* [mtouch] Don't look for assembly references in attributes in assemblies we ship. Partially fixes#49087.
Don't look for assembly references in attributes in assemblies we ship,
because it takes a significant amount of time to do this, and we can
precompute the fact that there aren't any such assembly references.
Additionally add a test to ensure we catch any changes to this assumption.
For a simple test app this makes rebuilding (without any changes) go from
~1.1s to ~0.4s.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [tests] Simplify tests to not use [TestCaseSource].
Using [TestCaseSource] is nice when running from the IDE, since it shows all
test cases in the test tree.
Unfortunately it causes the console runner to freak out [1], because the method
that lists all the test cases calls Configuration's cctor, which calls
TestContext.CurrentContext.TestDirectory, which is apparently not safe this
early in the test run.
[1] I think 'freak out' is the appropriate term for this behavior, which has
absolutely no direct nor obvious connection to the cause of the problem:
System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL 93a78115_c0da_4b6a_9661_9f9b9d9fb935/6669afd6_4.rem. An appropriate channel has probably not been registered.
Server stack trace:
at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <270c90abbc234cde9d33eb198a97cf71>:0
Sometimes streams won't write null when done, which means that if we wait
indefinitely for this to happen, we'll effectively deadlock.
Instead have a 1s timeout, after which we consider that we've captured
everything we need.
Example: https://jenkins.mono-project.com/job/xamarin-macios-pr-builder/3771/Test_Report/
(the test run hangs waiting for the mtouch tests, which finished pretty much instantly).
Use our Cache.CreateTemporaryDirectory method which will clean up the test
directories on the next test run (instead of when a test is done).
This makes it easier to inspect temporary test files after a test has
completed.
The generated registrar code must be built with -DDYNAMIC_MONO_RUNTIME so that
it references our local mono functions which do a dynamic function lookup.
This fixes an issue where release builds that don't embed mono fails to link,
because there are numerous unresolved externals pointing to mono symbols.
I don't quite understand VSfM's problem with the existing configuration (it
wouldn't build mmptest, claming an invalid solution configuration), but
hopefully these will work fine.
* [generator] Create CVPixelBuffer using GetINativeObject so its usable from 3rd party bindings
Complements https://bugzilla.xamarin.com/show_bug.cgi?id=52665
and PR #2102
CVPixelBuffer was created using the internal handle ctor, this
did not allow 3rd party bindings to bind it correctly since it
generated not compilable code.
We now use Runtime.GetINativeObject<CVPixelBuffer> (ptr, false); just
like the base ctor https://git.io/vHvLj.
* [tests] Add IntPtr.Zero check and fix link in code
* [generator] Make comment easier to find
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
[registrar] Support 'out' parameters from NULL pointers. Fixes#54919.
Native code doesn't have the 'out' and 'ref' distinction C# has, and passes
NULL around left and right.
So make sure the generated code from the static registrar doesn't write to such NULLs.
https://bugzilla.xamarin.com/show_bug.cgi?id=54919
Some namespaces are missing on generated files, causing error CS0246
The type or namespace name `Foo` could not be found.
While fixing this another error arose, by enabling the following test
[Protocol] interface C140 : ICIImageProcessorInput {}
some codepaths leads to CVPixelBuffer creation which our code
tries to invoke the handle ctor and fails to find it because it
is internal. This will be fixed in a different commit.
The minimum size for RSA keypairs is 1024 bits on macOS while it is
512 bits on iOS. Some tests using the minimum size (because we test the
API not the security) were disable on macOS. This re-enables them using
the platform minimum.
https://bugzilla.xamarin.com/show_bug.cgi?id=51277
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
- 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
This affects introspection-ios/introspection-mac (which are now grouped in an
`introspection` test), and dontlink-mac (which now shows up in the `dont link`
tests).
* [ObjCRuntime] Remove XM limitation. Fixes#55857.
I can't remember why I added this limitation, and git history provides now
clues.
Everything compiles without the limitation, and the bug is fixed, so I can't
see a reason not to fix it.
https://bugzilla.xamarin.com/show_bug.cgi?id=55857
* [tests] Run xammac tests both in Debug and Release configurations.
* [mmp/mtouch/ObjCRuntime] Calculate the path to the runtime-options.plist using NSBundle's ResourcePath.
The anatomy of apps and frameworks differ between iOS and macOS:
* iOS: we put runtime-options.plist in the root directory of the app.
* macOS:
* for apps we put runtime-options in foo.app/Contents/Resources
* for frameworks we put runtime-options in foo.framework/Versions/Current/A/Resources
Luckily NSBundle's ResourcePath property returns exactly this path, so change
our logic to use this property.
Also calculate the NSBundle using an exported type we know we have (using the
main bundle won't work when we're a framework).
* [tests] Add mmp/mtouch tests to verify the default HttpClientHandler according to build arguments.
* [ObjCRuntime] Use a custom class for finding the bundle.
Use a self-defined custom class to find the bundle where our resources are.
Using the internal NSObject.NSObject_Disposer class doesn't work when this
file (RuntimeOptions.cs) is compiled into System.Net.Http.dll.
* [tests] Convert mmp tests to a standard NUnit test library.
* [xharness] Add support for restoring nugets before building projects.
And restore nugets for tests-mac.sln before building mac test projects.
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
- SecCertificateCopyEmailAddresses behaves differently on macOS than iOS with
macOS getting the "documented" behavior of returning an empty array and iOS
returning null.
- Fix the test to just accept null or 0 elements
This dramatically decreases the size of watchOS apps built for debug when
using frameworks, because it ends up removing all the bitcode from
Mono.framework.
https://bugzilla.xamarin.com/show_bug.cgi?id=55256
Of particular importance is if we're building for LLVM or not: this fixes a
bug where we wouldn't pass --llvm to the AOT compiler when compiling
assemblies to frameworks (which we do when sharing code).
https://bugzilla.xamarin.com/show_bug.cgi?id=55555
* Remove the MT0008 test, since the error will never be shown again.
* Check non-existent root assemblies and report MT0018 instead of MT0007 if
they look like command-line arguments.
* Collect all MT0018/MT0007 errors before reporting any of them.
* Use Visual Studio instead of Xamarin Studio.
* VS doesn't have mdtool, it has vstool.
Also there's no need to manually invoke the mdtool.exe executable anymore
(which we did because the mdtool executable had a min macOS version of 10.9,
and we used to build tests on older macOS versions [1]), since now we only run
tests on older macOS versions, we don't build those tests there.
[1] a1932b0ccd
* [CoreText] Fix bug 54148 - CoreText.CTParagraphStyle does not pick up settings from CTParagraphStyleSettings
https://bugzilla.xamarin.com/show_bug.cgi?id=54148
CTParagraphStyle float properties have the incorrect float return type,
the headers state this API's returns CGFloats (aka nfloat) instead of floats
this used to work ok fetching them due to there is no difference in size
for 32 bits devices but once 64 bit devices appeared the API began to fail
The actual method that fetches the values `CTParagraphStyleGetValueForSpecifier`
asks for the size of the returned data and we used to give the size of a float
which is incorrect in 64 bits devices and the API call just correctly returned
false because it could not write back the value to us.
Added tests for the full properties available on CTParagraphStyle
* Add comment about the weird Dispose method implementation in CreateFromSettings
We want to copy the aot data for both the 32-bit and the 64-bit versions of an
assembly even if the 32-bit and 64-bit versions of the assembly are identical.
https://bugzilla.xamarin.com/show_bug.cgi?id=54499
- Before this mmp was not adding -framework, -weak_framework consistently on non-static registrar use cases
- GatherFrameworks was previously not ported from mtouch, and did not work as DeploymentTarget was unset in mmp
- Added verbose prints so users can determine why various framework linkages are added
- Fixed an issue where duplicate were being added due to HandleFramework shoving args by hand
- Tested with auto test and https://github.com/chamons/xm-version-regression-test manual test
Roslyn, when building in release, can remove unused fields. That broke
a test that ensure OpenTK types got preserved correctly (because the
assembly is not needed/included without that reference)
https://bugzilla.xamarin.com/show_bug.cgi?id=54466
This optimization is now limited to Xamairn.iOS.dll. 3rd parties .dll
size savings were not large enough to justify two different (32/64)
assemblies in the application bundle.
It's likely this change that resulted in incorrect fixes like:
- if (classic_or_sim || single_arch) {
+ if (IsMainExecutableDual ())
which reversed the condition and later
580f502777
which disabled DEBUG - but we don't have IL on release so it became
never executed.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=54408
- In some build cases this chunk of code:
<ItemGroup Condition=" '$(NoCompilerStandardLib)' == 'true' and '$(NoStdLib)' != 'true' ">
<!-- Note that unlike VB, C# does not automatically locate System.dll as a "standard library"
instead the reference is always passed from the project. Also, for mscorlib.dll
we need to provide the explicit location in order to maintain the correct behaviour
-->
<_ExplicitReference Include="$(FrameworkPathOverride)\mscorlib.dll" />
</ItemGroup>
would trigger and force us to use mscorlib from system mono. That does not work well.
- By setting FrameworkPathOverride, we can get the right mscorlib
- However, that ItemGroup happens outside of a target, so we must move our setting to match for it to take effect
* [tests] Don't create test packages by default.
Don't create test packages by default, instead add a new target to create test
packages. This new target is called on wrench, which means the packages will
still be created when needed, but they won't be built locally in every build
(and if a packaged test fails to build, it won't fail the entire build).
* [tests] Use a project reference instead of assembly reference for GuiUnit.exe
Use a project reference instead of assembly reference for GuiUnit.exe, so that
the GuiUnit reference is automatically built if necessary.
This also makes it required to build a sln for Classic (since mdtool can't
find referenced projects from a csproj).
In a6b9c28975 I fixed SystemSoundTest.FromFile
to not crash randomly, and at the same time I added an assert to ensure that
the playback completion handler is called properly, with a 10s timeout.
Which won't work, because the audio file is 23s long.
There's no need for a 23s audio file, so the fix is simple: cut the audio file
to 0.3s instead.
https://bugzilla.xamarin.com/show_bug.cgi?id=54236
Add an assembly registration event, that allows apps to opt out of
Xamarin.Mac's default behavior to recursively load every assembly referenced
by the entry assembly.
This is only for Xamarin.Mac, since it does not make sense to have this API in
Xamarin.iOS because assemblies are statically registered at build time.
Fixes bug #52575: Missing ModelIO API
(https://bugzilla.xamarin.com/show_bug.cgi?id=52575)
We turn the MDLMesh constructors into static ones because we don't want to lose the shape name.
Also, the signatures of these constructors differ so it would not be possible to use an enum to differentiate the shapes.
iOS 10.3 simulator (i386 only) will crash executing CTLineTests.
EnumerateCaretOffsets test case.
This does not happen on 64 bits (simulator) or on device builds,
including 32 bits builds. Running iOS 10.1 simulator (with Xcode 8.3)
also runs without problems.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=52162
They were thought to be macOS only but xtro corrected me, they are
new in iOS 10.3 even if some existed previously.
references (xtro):
!missing-pinvoke! SecCertificateCopyCommonName is not bound
!missing-pinvoke! SecCertificateCopyEmailAddresses is not bound
!missing-pinvoke! SecCertificateCopyNormalizedIssuerSequence is not bound
!missing-pinvoke! SecCertificateCopyNormalizedSubjectSequence is not bound
!missing-pinvoke! SecCertificateCopyPublicKey is not bound
!missing-pinvoke! SecCertificateCopySerialNumber is not bound
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=52505
There's a lot of noise from the header diff, e.g. tabs changed to spaces,
but very few actual changes.
Note that there's more macOS specific code to review but this PR
handles iOS, tvOS and watchOS changes.
* Updated API to reflect Xcode 8.3 beta 1 changes
* This commit also fixes availability metadata to avoid duplicating it
by moving member availability metadata into its container class where
possible.
* Enables VideoToolbox tests for tvOS.
Covers iOS, tvOS and macOS (no Metal on watch yet)
Most new members are _marked_ as @required (but are not really) by
Apple. We cannot make them `abstract` as it would be a breaking change.
The new field and both selectors are not really part of tvOS.
The field is not used anywhere (from available API).
The selectors are on a category on a type that is not part of tvOS.
Sadly they do not get annotated directly and require external data.
* introspection-ios
MPMusicPlayerControllerMutableQueue and MPMusicPlayerControllerQueue's headers show no trace of NSCoding, NSSecureCoding or NSMutableCopying therefore we're skipping them.
The exact values are not what we need to test for and varies with
different OS versions - making tests fails for no good reason (i.e.
they are not canary used to detect changes)
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=51801
Apparently Xcode 8.3 does not like the iPhone 5s simulator, and deletes it.
Every time Xcode is updated.
Which is slightly annoying when it affects the bots, since then iPhone 5s have
to be re-created on every bot.
So succumb to the pressure, and switch to using the iPhone 6 simulator instead.
https://bugzilla.xamarin.com/show_bug.cgi?id=53076
When [Async] was used on a member of a [Model][Protocol][Basetype]
interface the ModelClass ended up with additional FooAsync methods that
are not really part of the Model.
This commit removed any instances of FooAsync members from model classes
and also fixes any breaking changes in the currently bound classes.
Added test case using Model.
build diff:
https://gist.github.com/dalexsoto/75cb8424f2462bd6b513049f00bba6a8
Currently we get a CS2019 warning whenever we use AsyncAttribute
because we ignore the `result` variable on methods whose return
type is != `void` which is the expected behaviour.
This is specially more annoying on third party bindings,
the generated code did not disable this warning so you get
an "unfixable" warning on the generated code and the user
has no way to fix this on their own.
We now disable and restore CS2019 in the generated code as needed.
Nobody likes warnings that are not their fault.
Added unit test.
Build diff:
https://gist.github.com/dalexsoto/6f57d3f84b039b9fda863e2f8cfcf365
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.
SystemSoundTest.FromFile was requesting to be called back when the sound
completed playback. This causes problems when the sound is disposed after it
has started playing, because in that case disposing it won't prevent the
callback from being called, but instead random InvalidCastExceptions / crashes
would occur.
https://bugzilla.xamarin.com/show_bug.cgi?id=52903
* SystemSound.PlaySystemSound doesn't work in the simulator.
https://stackoverflow.com/a/24973240/183422
Simplify mac tests by using different variables for the various flavors of mac
generators, and use these new flavors so that all tests pass when using the
IKVM-based bgen.
* [generator] Fix bug 42742 The advice attribute doesn't make it to the generated code
https://bugzilla.xamarin.com/show_bug.cgi?id=42742
The Advice attribute used in our bindings was not making
into the generated code. This fixes it.
Also added unit test for it
* [generator] Merged PrintFooAttributes into one
Merged PrintPlatformAttributes, PrintPreserveAttribute and
PrintAdviceAttribute into a single method PrintAttributes.
This is due to sometimes we call three times in a row the same method:
```csharp
PrintPlatformAttributes (pi.GetGetMethod ());
PrintPreserveAttribute (pi.GetGetMethod ());
PrintAdviceAttribute (pi.GetGetMethod ());
```
We now do
```csharp
PrintAttributes (pi, platform:true, preserve:true, advice:true);
```
Also removed a not used instance (internal field) of AdviceAttribute
* [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/
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.
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
* 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
* [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.
Fixes this warning:
Makefile:163: warning: overriding commands for target `virtualwrap'
Makefile:40: warning: ignoring old commands for target `virtualwrap'
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.
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]
Deleting the directory when the test completes just makes it harder to copy-
paste the failing command.
Any directories created by Cache.CreateTemporaryDirectory will automatically
be deleted at the next test run, so this won't use up disk space.
* [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
Cache the result of log parsing. This avoids re-reading gigabytes of log files
every second when the web page requests an updated version of the report.
Change how the registrar calls mtouch a bit, so that we don't use API that
throws an exception with the entire output in the exception message.
The problem is that if the process has a lot of output, XS slows down to a
crawl when showing the exception message in the test result pad.
Instead print the output to the terminal.
* [tests/link sdk] Remove defines that are set by default.
And these defines varies by platform, which means they're not correct for tvOS/watchOS.
* [tests/link sdk] Fix watchOS version check.
Change how the registrar calls mtouch a bit, so that we don't use API that
throws an exception with the entire output in the exception message.
The problem is that if the process has a lot of output, XS slows down to a
crawl when showing the exception message in the test result pad.
Instead print the output to the terminal.
Rolf Bjarne Kvinge
Alex Soto
Chris Hamons
Andi McClure
Sebastien Pouliot
Zoltan Varga
Marek Safar
Vincent Dondain
Manuel de la Pena
Alex Soto
Timothy Risi