-
Notifications
You must be signed in to change notification settings - Fork 52
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[generator] deep clone methods to avoid NREs (#1080)
Context: 4ec5d4e Context: #1083 Context: `generator` crash while binding Google Material 1.6.1 Imagine: 1. A `public` class that inherits from a *package-private* class, and 2. The *package-private* class contains `public` or `protected` members which should be exposed on (1). For example: /* package-private*/ class BaseClass<V> { public void doThing(V value) {} } public class MyClass extends BaseClass<Object> { } We won't bind `BaseClass<V>` as it is *package-private*, but we want (need) it's publicly accessible members to be available to users of the `public` type `MyClass`; that is, *in Java*, `MyClass.doThing(Object)` will be an accessible method, and our binding of `MyClass` should likewise have a `MyClass.DoThing(Object)` method binding. In 4ec5d4e we supported this scenario by copying members from the *package-private* base class into the derived class. Or at least, that's what the commit says it does. It does not actually create a *copy* of the `Method`; rather, it simply adds the existing `Method` instance to the public derived class, meaning that the same `Method` instance is referenced by both the base & derived types! In general, this is fine. However consider `BaseClass<V>`, above: the derived type `MyClass` doesn't have a generic type argument `V`, and thus "copying" `BaseClass<V>.doThing(V)` as-is into `MyClass` is a non-sequitur; when we later `Validate()` the `Method` instance, this incongruity is detected and a warning is emitted: warning BG8800: Unknown parameter type 'V' for member 'MyClass.DoThing(V)'. As part of validation, the `Method` instance is also marked as invalid, by setting the `MethodBase.IsValid` property to `false`, and the instance is removed from `GenBase.Methods` for `MyClass`. Unfortunately that's not the end of it, because the `Method` instance is shared and thus is also in the `GenBase.Methods` collection for `BaseClass<V>`. This instance is expected/assumed to be valid, but was invalidated by `MyClass` validation. `generator` assumes that after validation, everything within `GenBase.Methods` is still valid. This assumption is no longer true for `BaseClass<V>`. The result is that if we later attempt to process `BaseClass<V>`, things blow up when trying to use the parameter types on `BaseClass<V>.doThing(V)`: System.NullReferenceException: Object reference not set to an instance of an object. at MonoDroid.Generation.Parameter.get_JniType() in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\Parameter.cs:line 103 at MonoDroid.Generation.ParameterList.get_JniSignature() in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\ParameterList.cs:line 203 at MonoDroid.Generation.Method.get_JniSignature() in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\Method.cs:line 210 at MonoDroid.Generation.GenBase.ContainsMethod(Method method, Boolean check_ifaces, Boolean check_base_ifaces) in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\GenBase.cs:line 225 at MonoDroid.Generation.GenBase.ContainsMethod(Method method, Boolean check_ifaces) in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\GenBase.cs:line 208 at MonoDroid.Generation.GenBase.FixupMethodOverrides(CodeGenerationOptions opt) in C:\code\xamarin-android\external\Java.Interop\tools\generator\Java.Interop.Tools.Generator.ObjectModel\GenBase.cs:line 341 The fix is "simple": do what 4ec5d4e said it was doing and make a *copy* of the `Method` instance using a new `Clone()` method. With this fix, the copied method will be invalidated and removed without corrupting the original `Method` instance. *Note*: As seen in the unit test changes, the XPath comments are updated to point to the public type rather than the original package- private type. While this isn't "correct", neither was the previous XPath specification. After discussion, we have decided that the needed change is to not add XPath comments on "created" methods (that is, API that is created by `generator` and is not part of the Java public API). However, the cost of doing this change is higher than we currently wish to spend, so we will live with this minor issue for now. TODO: #1083 suggests a "complete fix" which allows `BaseClass<V>.doThing(V)` to be bound as `MyClass.DoThing(Object)`.
- Loading branch information
Showing
10 changed files
with
126 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters