* [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
This avoids the following compiler warning:
/Applications/Xcode83.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:5:2: warning: gl.h and gl3.h are both included. Compiler will not invoke errors if using removed OpenGL functionality. [-W#warnings]
I found the magic symbol by looking at the headers.
* [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
Fixes this compiler warning:
/work/maccore/master/xamarin-macios/tools/common/DerivedLinkContext.cs(12,28): warning CS0649: Field 'DerivedLinkContext.StaticRegistrar' is never assigned to, and will always have its default value null
and makes the mmp code closer to mtouch.
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).
Make sure to instantiate an Assembly instance for every assembly loaded using
the cached list of assemblies.
Fixes the following test failures:
1. Xamarin.MTouch.RebuildTest_WithExtensions("single","",False,System.String[]) : second build
Expected: 0
But was: 1
2. Xamarin.MTouch.RebuildTest_WithExtensions("dual","armv7,arm64",False,System.String[]) : second build
Expected: 0
But was: 1
3. Xamarin.MTouch.RebuildTest_WithExtensions("llvm","armv7+llvm",False,System.String[]) : second build
Expected: 0
But was: 1
4. Xamarin.MTouch.RebuildTest_WithExtensions("debug","",True,System.String[]) : second build
Expected: 0
But was: 1
5. Xamarin.MTouch.RebuildTest_WithExtensions("single-framework","",False,System.String[]) : second build
Expected: 0
But was: 1
* [mtouch] Cache the list of assemblies we computed. Partially fixes#49087.
Computing the list of assemblies can be expensive, so cache it and re-use the
cached list if we can.
https://bugzilla.xamarin.com/show_bug.cgi?id=49087
* [mtouch] Create directory before trying to create files to it.
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.
This XM-only RemoveSelectors works on FieldDefinition but in some cases,
e.g. inside a generic types, it's FieldReference that are encoded. This
meant the static constructor was not re-written correctly and would throw
a TargetInvocationException (since the fields were removed correctly)
https://bugzilla.xamarin.com/show_bug.cgi?id=55693
`csc` without `/optimize` generates different IL, including additional
and not required load and store instructions. We previously ignored them
but that could leave the stack unbalanced leading to runtime exceptions.
We are now nop'ing the extraneous instructions (same as the rest of the
unneeded branch code)
This fixes#53872 [1] and also the known parts of #56209 (the other parts
are still NEEDINFO and could, possibly, be unrelated).
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=53872
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=56209#c2
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
* [ObjCRuntime] Only use a 'BundleFinder' class when we don't have another internal type we can use. Fixes#56255.
Inside our platform assemblies, we can use the NSObject.NSObject_Disposer
class to find the bundle (this class is not binding an existing Objective-C
class, which would make it unusable for this purpose, and it's also needed
always, which means we're not adding unnecessary bloat to linked platform
assemblies).
However, for System.Net.Http.dll, I couldn't find any publicly visible type
that would fit those criteria, so we're still using a custom 'BundleFinder'
class.
https://bugzilla.xamarin.com/show_bug.cgi?id=56255
* [ObjCRuntime] Use an InternalsVisibleTo attribute to always use NSObject_Disposer to find the bundle.
Make our platform internals visible to System.Net.Http.dll so that we an use the NSObject_Dispose type there as well.
- 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
* [src] Rebuild Constants.cs when Make.config.inc changes.
Also unify the makefile targets/dependencies for the various Constants.cs recipes.
* [build] Fix dependencies for various installed files.
Some auto-generated installed files with version numbers must depend on
Make.config.inc, since that's where the revision number is stored.
Make.config.inc depends on Makefile, so there's no need to depend on Makefile
as well.
* [build] Fix build error.
I've spent way too much time looking at the console waiting for things to
appear, all the while a dialog has hid away beneath other windows on my
system, waiting indefinitely for my attention.
* [runtime] Fix broken indentation to make code less confusing.
* [runtime] Rework initialization for Xamarin.Mac extensions.
1. Delay the Application.Init execution from step 6 in the initialization
sequence, to when we'd run the managed Main function for a normal app. This
makes the code a bit easier to reason about, since both code paths behave
more similar. It's also matches the initialization documentation better
(step 6 is "find the executable", not "find the executable and run
Application.Init").
2. Install custom callbacks for mono's logging function just before calling
Application.Init. We already install these custom callbacks in
xamarin_initialize, but that doesn't help much if something goes wrong
before xamarin_initialize is called (and there's no harm in doing this
twice).
3. Treat the extension dll as an entry assembly, make the path to the entry
assembly available to managed code, and load this assembly if
Assembly.GetEntryAssembly can't find it (which happens for extensions,
since there's no entry point as Assembly.GetEntryAssembly defines an entry
assembly).
This fixes launching of Xamarin.Mac extensions.
* [runtime] Spaces -> tabs.
commit migueldeicaza/MonoTouch.Dialog@c2c64825ba
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Wed May 10 11:09:16 2017 +0200
Fix tvOS compiler warning.
Fix never assigned warning by conditionally remove all usages and the
definition of the variable (instead of just some usages):
> MonoTouch.Dialog/MonoTouch.Dialog/DialogViewController.cs(47,15): warning CS0649: Field 'DialogViewController.searchBar' is never assigned to, and will always have its default value null
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).
Alex Soto
Rolf Bjarne Kvinge
Timothy Risi
Sebastien Pouliot
Chris Hamons