| Age | Commit message (Collapse) | Author |
|---|
|
PiperOrigin-RevId: 397354545
|
|
PiperOrigin-RevId: 397209445
|
|
PiperOrigin-RevId: 387664991
|
|
PiperOrigin-RevId: 386487552
|
|
PiperOrigin-RevId: 385446789
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=274657681
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=260768075
|
|
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=257436949
|
|
MOE_MIGRATED_REVID=251930479
|
|
MOE_MIGRATED_REVID=225619145
|
|
instead of failing eagerly on the first error. If there are multiple
missing symbols it's usually more helpful to report them all at once.
MOE_MIGRATED_REVID=221365669
|
|
and use them to represent type variable bounds.
MOE_MIGRATED_REVID=220363183
|
|
MOE_MIGRATED_REVID=218773246
|
|
in order to get equals and hashCode implementations.
MOE_MIGRATED_REVID=218399705
|
|
Propagate position information from the nearest tree to the type being
canonicalized, and report an error if a missing symbol is encountered.
MOE_MIGRATED_REVID=213706370
|
|
MOE_MIGRATED_REVID=192318366
|
|
MOE_MIGRATED_REVID=192185656
|
|
It's possible for a class A to be both a sub-class and the enclosing
instance of another class B:
```
class Test {
class B {}
class A extends B {
A.B f;
}
}
```
During canonicalization we don't need to consider both possibilities
simultaneously. When canonicalizing B as a member of A we end up
canonicalizing A's super-type, but the enclosing instance for the second
step should be A's outer class, not A itself. This was causing
canonicalization to get stuck in an infinite loop on examples like the
one above.
MOE_MIGRATED_REVID=179932866
|
|
MOE_MIGRATED_REVID=139378957
|
|
Handle binding of type annotations, evaluation of type annotation
arguments, and lowering to bytecode for all type annotations kinds that
can appears in headers.
Currently type annotations are identified syntactically, we need to read
@Target to deal with ambiguous declarations on fields and method return
types (e.g. `@A int x;` could be `TYPE_USE` or `FIELD` or both).
MOE_MIGRATED_REVID=137566512
|
|
Instantiate types recursively; previously [T/e]A<T> worked but
[T/e]A<B<T>> didn't.
Also handle instantiating arrays with parametric element types, which
can't appear as top-level types during canonicalization but can appear
as type arguments (e.g. [T/e]A<T[]> -> A<e[]>).
The array instantiation case is interesting because it allows the
creation of arrays with wildcard element types. The JVMS signature
grammar [1] doesn't actually allow that, but both javac and ecj can be
coerced into emitting it:
class A<X> { class I {} }
class Test {
class B<Y> extends A<Y[]> {}
B<?>.I i; // LA<[*>.I;
}
To support this, restructure the type and signature models to make
wildcards first-class types, instead of only allowing them as top-level
type arguments.
[1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.9.1
MOE_MIGRATED_REVID=137101539
|
|
MOE_MIGRATED_REVID=137061193
|
|
Initial constant field handling. Currently only literal values and
references to other fields are supported, constant expression evaluation
will be added later. Includes class file writing support for additional
literal kinds.
MOE_MIGRATED_REVID=135506016
|
|
Canonicalize qualified type names so qualifiers are always the declaring
class of the qualified type. For example, given:
```
class A<T> { class Inner {} }
class B extends A<String> {}
```
The type name `B.Inner` must be canonicalized as `A<String>.Inner` in bytecode.
MOE_MIGRATED_REVID=135300804
|
