are JVM annotations used by Java's generics support. They cannot be used
for FPC's generics support, but they are useful in other cases
* emit classrefdefs as java.lang.Class, with a signature annotation that
indicates which class they actually refer to
git-svn-id: branches/jvmbackend@18534 -
with java_jlstring in that case, because we have to insert the type
without L prefix and ; suffix for that opcode (which is not done for
objectdefs/recorddefs)
git-svn-id: branches/jvmbackend@18530 -
typeconversion handling
+ support for class reference types in the JVM (although without class virtual
methods, they're not that useful)
git-svn-id: branches/jvmbackend@18516 -
cannot insert typecasting checks on the assignment side, only on the
values that are being assigned
o since valid_for_assignment() is called in tassignmentnode.typecheckpass()
after typecheckpassing left and right, moved the conversion of the
typecheck nodes into JVM-specific constructs from typecheckpass to
pass_1, so that they can use the information whether they are on
the assignment side or not
* forbid casting a child type to a parent type on the assignment side on
managed platforms, because that circumvents the type checking
git-svn-id: branches/jvmbackend@18515 -
only JVM constructs that are already implemented, but also ones that
will be supported in the future but that aren't implemented yet (to
make it easier to already adapt code to the future changes)
git-svn-id: branches/jvmbackend@18498 -
the types as declared in the system unit, since they can also be
used with equivalent but different types (e.g., byte vs shortint)
git-svn-id: branches/jvmbackend@18487 -
in a single statement, to be added later)
o the unicodestrings are internally simply java.lang.String instances
o at the language level, the unicodestrings are assignment-compatible
with java.lang.String
o constant strings can be implicitly converted to java.lang.String
o since java.lang.String is immutable, in particular changing a
single character in a string is extremely inefficient. This could
be solved by letting unicodestring map to java.lang.StringBuilder,
but that would make integration with plain Java code harder
git-svn-id: branches/jvmbackend@18470 -
asis_target_specific_typecheck, and if so get the real
definition of its pointedtype rather than of the classrefdef
itself (the latter would never be different from the original
one, since there are no formal external classrefdef definitions)
git-svn-id: branches/jvmbackend@18467 -
fpcbaserecordtype for the JVM target (intercept in ncnv via new
target_specific_general_typeconv helper, handle in as/is code)
* not only check for related types in htypechk in case they are
objdefs, but always do so (records are related to jlobject/fpcbaserecord
on the JVM target)
git-svn-id: branches/jvmbackend@18458 -
to tasnode (like for regular Object Pascal classes)
* don't collect WPO information for Java classes in tloadvmtaddrnode.pass_1()
(devirtualization can't work for Java, since classes can always be loaded
at run time, except for final/sealed classes -- but that's not yet
implemented)
+ JVM is-node support, unified JVM type checking codegen for is- and as-nodes
git-svn-id: branches/jvmbackend@18383 -
o since the JVM does not support call-by-reference, setlength() works
by taking an argument pointing to the old array and one to the new
array (the latter is always created in advance on the caller side,
even if not strictly required, because we cannot easily create it
on the callee side in an efficient way). Then we copy parts of the
old array to the new array as necessary
o to represent creating a new dynamic array, the JVM target uses
an in_new_x tinlinenode
+ tasnode support for the JVM. Special: it can also be used to convert
java.lang.Object to dynamic arrays, and dynamic arrays of java.lang.Object
to dynamic arrays with more dimensions (arrays are special JVM objects,
and such support is required for the setlength support)
+ check whether explicit type conversions are valid, and if so, add the
necessary conversion code since we cannot simply reinterpret bit patterns
in most cases in the JVM:
o in case of class and/or dynamic array types, convert to an as-node
o in case of int-to-float or float-to-int, use java.lang.Float/Double
helpers (+ added the definitions of these helpers to the system unit)
git-svn-id: branches/jvmbackend@18378 -
