Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[generator] Deriving from certain protocol interfaces generates uncompilable code. Fixes bug 52665 #2102

Merged
merged 2 commits into from May 18, 2017

Conversation

dalexsoto
Copy link
Member

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 code paths lead 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.

build diff: https://gist.github.com/dalexsoto/055381e7aebecca254139bd6cca6a2e8

…pilable code. Fixed bug 52665

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.
@monojenkins
Copy link
Collaborator

Build success

@spouliot spouliot requested a review from rolfbjarne May 18, 2017 00:03
src/generator.cs Outdated
@@ -717,6 +717,19 @@ public NamespaceManager (string prefix, string customObjCRuntimeNS, bool skipSys
if (Frameworks.HaveMetal && !(Generator.CurrentPlatform == PlatformName.MacOSX && !Generator.UnifiedAPI))
ImplicitNamespaces.Add (Get ("Metal"));

if (Frameworks.HaveCoreImage && !(Generator.CurrentPlatform == PlatformName.WatchOS))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need the additional platform checks?

In the code above they're only there to not change the generated output when I ported the code to use IKVM; in theory those checks can be removed (but when porting to IKVM I preferred fixing one thing at a time, minimizing the diff in the generated output).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, It would be cleaner/simpler without them 👍

@dalexsoto
Copy link
Member Author

@rolfbjarne / @spouliot Fixed 👍

Copy link
Contributor

@spouliot spouliot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

much nicer:)

@dalexsoto at a lower priority (after 15.3 issues) can you do a separate PR to remove the other extra conditions. thanks!

@dalexsoto
Copy link
Member Author

@spouliot noted, will do!

@monojenkins
Copy link
Collaborator

Build success

@spouliot spouliot merged commit 9621842 into xamarin:master May 18, 2017
@dalexsoto dalexsoto deleted the bug52665 branch May 19, 2017 02:15
dalexsoto added a commit to dalexsoto/xamarin-macios that referenced this pull request May 19, 2017
… from 3rd party bindings

Complements https://bugzilla.xamarin.com/show_bug.cgi?id=52665
and PR xamarin#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.
dalexsoto added a commit that referenced this pull request May 19, 2017
… from 3rd party bindings (#2111)

* [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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants