Commit d7dfa0b
[generator] Better support aliased types (#173)
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56436
`generator` relies on the existance of a mapping from Java types to
managed types which bind the Java type. The `generator --ref` option
will cause `generator` to make this mapping based on the managed types
from an assembly, and the mapping in turn is handled by `[Register]`
and related custom attributes:
namespace Android.Runtime {
[Register ("java/util/Collection", DoNotRegisterAcw=true)]
partial class JavaCollection {
}
}
For better or worse, nothing enforces that there be only one such
mapping, It is thus possible to have multiple types partake in the
mapping process:
namespace Java.Util {
[Register ("java/util/Collection", DoNotRegisterAcw=true)]
partial interface ICollection {
}
}
A Java type is *aliased* when two or more managed types bind the same
Java type, as with the above `Android.Runtime.JavaCollection` and
`Java.Util.ICollection` types;
This is a scenario which as long existed.
Question: What does `generator` do when a type is aliased?
Answer: `generator` registers mappings from assemblies in the order of
types in the assembly it's processing. When an aliased type is found,
the *last registered type* "wins".
For example, if an assembly defines `JavaCollection` before
`ICollection`, then a type lookup for `java.util.Collection` will
return `ICollection`. If instead the assembly defines `ICollection`
before `JavaCollection`, then a type lookup for `java.util.Collection`
willl instead return `JavaCollection`.
This is not necessarily desirable, but I don't see much alternative.
Unfortunately, that's only *half* the scenario. There are a number of
situations in which `SymbolTable.Lookup()` is not given a Java name,
but is instead given the *managed binding type name*. In particular,
this happens when `ManagedClassGen.Validate()` is called, and it
attempts to validate the base class and all implemented interfaces,
using the *managed* type names for this process.
Here is where the "last registered type wins" behavior becomes
problematic, as it means that a Lookup for `Java.Util.ICollection` can
fail when `JavaCollection` is registered after `ICollection`, because
the Java name was shared.
Which brings us to Bug #56436: building a Xamarin.Android binding
project changes behavior based on whether Xamarin.Android 7.2 or
Xamarin.Android 7.3 is used, and the primary difference between these
differences is the order that types are defined in `Mono.Android.dll`.
In XA 7.2, `JavaCollection` is defined before `ICollection`.
In XA 7.3, `ICollection` is defined before `JavaCollection`.
This (subtle!) change interacts with `generator`, and within XA 7.3
means that `Java.Util.ICollection` can't be found:
warning BG8C00: For type Java.Util.AbstractQueue, base interface Java.Util.ICollection does not exist.
Improve this state of affairs by changing `SymbolTable.symbols` from a
`Dictionary<string, ISymbol>` to a `Dictionary<string, List<ISymbol>>`,
allowing `generator` to preserve all the managed types which bind a
given Java type. This in turn allows *both* `ICollection` and
`JavaCollection` to be preserved, so that a lookup for
`Java.Util.ICollection` will now work consistently, without any type
definition ordering issues.
Unfortunately lookups for the Java type `java.util.Collection` will
still be order-dependent, continuing to return the *last* registered
type. Hopefully this won't cause any problems.1 parent 0ff255e commit d7dfa0b
1 file changed
+25
-14
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
10 | | - | |
| 10 | + | |
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
| |||
32 | 32 | | |
33 | 33 | | |
34 | 34 | | |
35 | | - | |
| 35 | + | |
36 | 36 | | |
37 | 37 | | |
38 | 38 | | |
| |||
121 | 121 | | |
122 | 122 | | |
123 | 123 | | |
124 | | - | |
125 | | - | |
126 | | - | |
127 | | - | |
| 124 | + | |
128 | 125 | | |
129 | 126 | | |
130 | 127 | | |
| |||
138 | 135 | | |
139 | 136 | | |
140 | 137 | | |
141 | | - | |
142 | | - | |
143 | | - | |
144 | | - | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
145 | 146 | | |
146 | 147 | | |
147 | 148 | | |
| |||
254 | 255 | | |
255 | 256 | | |
256 | 257 | | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
257 | 265 | | |
258 | | - | |
259 | 266 | | |
260 | 267 | | |
261 | 268 | | |
| |||
279 | 286 | | |
280 | 287 | | |
281 | 288 | | |
282 | | - | |
283 | | - | |
284 | | - | |
| 289 | + | |
| 290 | + | |
| 291 | + | |
| 292 | + | |
| 293 | + | |
| 294 | + | |
| 295 | + | |
285 | 296 | | |
286 | 297 | | |
287 | 298 | | |
| |||
0 commit comments