Commit Graph

30 Commits

Author SHA1 Message Date
Jonas Maebe
a216707cf2 * also generate wrappers for inherited virtual class methods, because their
visibility can change. However, simply call the inherited version in
    those rather than re-adding the complete dispatching code again

git-svn-id: branches/jvmbackend@18737 -
2011-08-20 08:30:15 +00:00
Jonas Maebe
df5fc421ce + support for increasing the visibility of fields using properties
on the JVM target (at the Pascal level), by automatically generating
    getters/setters of the same visibility as the property that are used
    instead of directly accessing the fields when translating the property

git-svn-id: branches/jvmbackend@18724 -
2011-08-20 08:27:53 +00:00
Jonas Maebe
b3072b3dab * extracted the code to deal with static fields into a routine
(make_field_static() ) and replaced semi-duplicates of that
    code with calls to this routine
  * made the handling of static fields for the JVM target more
    similar to that on the other targets, so that class properties
    now also work there (-> updated JVM-specific code in several
    places to deal with this new handling)

git-svn-id: branches/jvmbackend@18723 -
2011-08-20 08:27:48 +00:00
Jonas Maebe
dbe55d1f6f * only override "clone" for records that contain fields that require a
deep copy, and for those records no longer call the inherited clone.
    Instead, declare a local variable of the record type, assign its
    address to the function and then copy all field contents to this local
    variable. Since it's dynamically allocated at the JVM level, it will
    survive the function exit.

    The problem with calling the inherited clone function is that it will
    copy the pointers of the implicit pointer fields (records, sets, …)
    from the old to the new instance, and that we (currently) have no way
    at the Pascal level to change those and make them point to new
    instances.

git-svn-id: branches/jvmbackend@18721 -
2011-08-20 08:27:37 +00:00
Jonas Maebe
3ac950eed7 * changed the parameter of fpcDeepCopy() from an out-parameter of the
actual recordtype into FpcBaseRecordType so we can also use
    the deep copy routine in the RTL
  + added abstract fpcDeepCopy() declaration to FpcBaseRecordType class

git-svn-id: branches/jvmbackend@18718 -
2011-08-20 08:27:22 +00:00
Jonas Maebe
d583243fbb * only generate the dispatch wrapper for virtual class methods and virtual
constructors in the base class that defines them, rather than also in
    every class that overrides them (since the dispatch routine is the same
    everywhere)

git-svn-id: branches/jvmbackend@18716 -
2011-08-20 08:27:11 +00:00
Jonas Maebe
ad871b6acd * automatically generate versions of inherited virtual class methods that
call through to the parent method in case they are not overridden in
    the child class, because otherwise the dynamic dispatch fails (looking
    up a class method only checks that particular class, since they are
    never virtual in Java and hence not inherited either)

git-svn-id: branches/jvmbackend@18715 -
2011-08-20 08:27:07 +00:00
Jonas Maebe
1d0388d40a + support for virtual constructors for the JVM platform. We simply
create a virtual class (factory) method that calls the constructor,
    and then let the existing support for virtual class methods handle
    everything

git-svn-id: branches/jvmbackend@18710 -
2011-08-20 08:26:40 +00:00
Jonas Maebe
e38cfc307b * renamed pc_procvar2bareproc to pc_bareproc, and allow it also to
be used to create bare procdef->procdef copy

git-svn-id: branches/jvmbackend@18709 -
2011-08-20 08:26:35 +00:00
Jonas Maebe
7d8cbe80f5 + support for virtual class methods on the JVM platform. The JVM does not
support those natively, so they are emulated via the procvar infrastructure
    (and hence not very fast). Could probably be optimized somewhat by adding
    a cache (hashmap of procvars) to the class hierarchies, maybe in the
    future.

git-svn-id: branches/jvmbackend@18704 -
2011-08-20 08:26:11 +00:00
Jonas Maebe
478a0376e3 * make sure that wrapped methods for property accesses are added to the
symtable of the current structdef

git-svn-id: branches/jvmbackend@18696 -
2011-08-20 08:25:29 +00:00
Jonas Maebe
4074bf412b - removed po_java procoption, since it wasn't really used for anything
git-svn-id: branches/jvmbackend@18694 -
2011-08-20 08:25:19 +00:00
Jonas Maebe
7e7bdc3c55 * make the real name of methods implementing interface methods the same as
as the real name of the declaration in the interface, so that the JVM
    case-sensitive mapping works out
  * process the interface mappings for the compiler-constructed classes for
    enums and procvars

git-svn-id: branches/jvmbackend@18693 -
2011-08-20 08:25:14 +00:00
Jonas Maebe
979f55e1db + support for procedural variables for the JVM target
o every porocedural variable type is represented by a class with one
     public "invoke" method whose signature matches the signature of the
     procvar
   o internally, dispatching happens via java.lang.reflect.Method.invoke().
     WARNING: while this allows calling private/protected or other methods
     that are normally not accessible from another context, a security
     manger can override this. If such a security manager is installed,
     most procvars will cause security exceptions
   o such dispatching also requires that all arguments are wrapped, but
     that's done in the compiler-generated body of the invoke method,
     so that procvars can also be called conveniently from Java code
   o typecasting between a procedure of object and tmethod is supported,
     as well as Delphi-style replacing of only the method pointer via
     @procvar1=@procvar2.
   o nested procvars are not yet supported, but most of the basic
     infrastructure for them is already present
  * all units/programs now get an internal __FPC_JVM_Module_Class_Alias$
    type when compiled for the JVM target, which is an "external" class
    that maps to the unit name. This is required to look up the
    JLRMethod instances for regular functions/procedures
  + new tabstractprocdef.copyas() method that allows to create a procvar
    from a procdef and vice versa

git-svn-id: branches/jvmbackend@18690 -
2011-08-20 08:24:58 +00:00
Jonas Maebe
5bf16214cd * changed initialization of records from constructing a new instance and
copying that over the old one into calling a dedicated fpcInitializeRec()
    method that initializes the required fields. The reason is that this
    initialization is performed for out-parameters, and the fpcDeepCopy()
    method (used to copy one instance over another) has an out-parameter
    -> infinite loop

git-svn-id: branches/jvmbackend@18674 -
2011-08-20 08:23:27 +00:00
Jonas Maebe
37aa2d8443 + full support for sets on the JVM target
o sets of enums are handled as JUEnumSet instances, others as JUBitSet
     derivatives (both smallsets and varsets, to make interoperability with
     Java easier)
   o special handling of set constants: these have to be constructed at run
     time. In case of constants in the code, create an internal constsym to
     represent them. These and regular constsyms are then aliased by an
     another internal staticvarsym that is used to initialise them in the
     unit initialisation code.
   o until they are constructed at run time, set constants are encoded as
     constant Java strings (with the characters containing the set bits)
   o hlcgobj conversion of tcginnode.pass_generate_code() for the genjumps
     part (that's the only part of the generic code that's used by the JVM
     target)
   o as far as explicit typecasting support is concerned, currently the
     following ones are supported (both from/to setdefs): ordinal types,
     enums, any other set types (whose size is the same on native targets)
   o enum setdefs also emit signatures
   o overloading routines for different ordinal set types, or for different
     enum set types, is not supported on the JVM target

git-svn-id: branches/jvmbackend@18662 -
2011-08-20 08:22:22 +00:00
Jonas Maebe
5ea497857d + FpcEnumValueObtainable interface that's implemented by all FPC
enums (for use in set factory helpers)

git-svn-id: branches/jvmbackend@18651 -
2011-08-20 08:21:24 +00:00
Jonas Maebe
386136ba7c * declare enumclass "values" method as "static" (necessary so that the JVM
recognises the class as a proper enum class)

git-svn-id: branches/jvmbackend@18650 -
2011-08-20 08:21:19 +00:00
Jonas Maebe
112d17af84 + support for local enum types (defined in procedures), by stuffing their
corresponding classes into the global symtable ("local classes" don't
    exist/work)

git-svn-id: branches/jvmbackend@18649 -
2011-08-20 08:21:15 +00:00
Jonas Maebe
b65422cd59 * make sure that the real name of enums is not replaced by the alias
typesyms we create

git-svn-id: branches/jvmbackend@18647 -
2011-08-20 08:21:05 +00:00
Jonas Maebe
e534a17c01 - removed unused scanner.tscannerstate, inserttext_begin and inserttext_end
(leftovers from the initial symcreat implementations that didn't work)

git-svn-id: branches/jvmbackend@18637 -
2011-08-20 08:20:13 +00:00
Jonas Maebe
1ad834f5f9 * in case a property uses a getter/setter with lower visibility than the
property, generate a wrapper with the same visibility as the property
    that calls through to the original getter/setter (JVM target only:
    ensures that the JVM verifier doesn't complain about calling methods
    that are not visible to the current class when using such properties
    from other units/classes)

git-svn-id: branches/jvmbackend@18632 -
2011-08-20 08:16:56 +00:00
Jonas Maebe
569228447d * converted all enum handling for the JVM target so that it uses the
JDK class-style enums rather than plain ordinals like in Pascal
   o for Pascal code, nothing changes, except that for the JVM target
     you can always typecast any enum into a class instance (to interface
     with the JDK)
   o to Java programs, FPC enums look exactly like Java enum types

git-svn-id: branches/jvmbackend@18620 -
2011-08-20 08:15:54 +00:00
Jonas Maebe
13b0ac91d9 + generate java.lang.Enum descendant classes for Pascal enum types
o these classes get an "enum" flag in the class files
   o these classes get a class field (whose type is that same enum
     class) per enum in the type, which also gets the "enum" flag
   o those class fields are initialised in the class constructor
     with the name of the enum and their order in the declaration
   o if the enum has jumps in FPC (lowest value is not 0, or not
     all values are contiguous), then we add an extra field
     to hold the FPC ordinal value of the enum
   o these classes get a class field valled $VALUES that contains
     a reference to the aforementioned class fields in order of
     declaration (= ordinal->instance mapping, JDK-mandated)
   o apart from the JDK-mandated instance methods (values, valueOf),
     also add FPCOrdinal (returns FPC ordinal value; same as order
     of declaration in case of no jumps) instance method and FPCValueOf
     (returns enum corresponding to FPC ordinal value) static class
     method
   o the mapping between FPC ordinals and enum instances in case of
     jumps is stored in a hashmap whose size is the next prime number
     greater or equal than the number of enum elements
   o moved several extra JDK types to the system unit for the enum
     support, and for future boxing and Java set support
   o several new synthetic method identifiers to generate the enum class
     methods/constructor/class constructor
   o enums with jumps are ordered by FPC ordinal value in the JVM
     $VALUES array so that the java.lang.Enum.doCompare() method
     will properly compare them

git-svn-id: branches/jvmbackend@18616 -
2011-08-20 08:15:28 +00:00
Jonas Maebe
9d0fdb3150 * explicitly specify symtable to jvm_guarantee_record_typesym() instead of
hardcoding symtablestack.top

git-svn-id: branches/jvmbackend@18585 -
2011-08-20 08:12:43 +00:00
Jonas Maebe
2610cea230 - removed orphan helpers
git-svn-id: branches/jvmbackend@18533 -
2011-08-20 08:07:54 +00:00
Jonas Maebe
df7100ff80 + support for anonymous record types for the JVM targets: automatically
generate a name and typesym for them

git-svn-id: branches/jvmbackend@18491 -
2011-08-20 08:04:16 +00:00
Jonas Maebe
834ea45be8 * (class_)constructor/destructor_head() now also parses hints,
handles modifiers and adds the procdefinition. This code was
    duplicated in several places (for objects and records)
  * properly handle introducing artificial class constructors
    (the manually constructed procdefs were wrong, now use
     str_parse_method_dec)

git-svn-id: branches/jvmbackend@18482 -
2011-08-20 08:03:33 +00:00
Jonas Maebe
e663f0f31f + support for class constructors for the JVM target
o initialise class vars that need initialisations (records, arrays) in
     class constructors
   o treat class constructors as having a "void" resultdef rather than the
     class type for JVM (maybe has to be done in general?)
   o make it possible to specify pno_noleadingdollar to
     tprocdef.customprocname() so it can be used for class constructors
     (their name is lower cased because it mustn't conflict with other
      identifiers, since their name doesn't matter anyway)
   o added tsk_empty synthetic procdef kind which, as the name implies,
     generates an empty body (for class generated constructors)
  + auto-generate class constructors in case a class has class vars that
    need initialisation

git-svn-id: branches/jvmbackend@18462 -
2011-08-20 08:01:51 +00:00
Jonas Maebe
40e0b4677a + support for (only named, for now) records in the JVM target:
implemented via classes, all descending from system.FpcBaseRecordType
    (records are also considered to be "related" to system.FpcBaseRecordType
     on the JVM target)
  * several routines are auto-generated for all record-classes: apart
    from a default constructor (if there is none), also clone (which
    returns a new instance containing a deep copy of the current
    instance) and deepCopy (which copies all fields of one instance
    into another one)
   o added new field "synthetickind" to tprocdef that indicates what
     kind of synthetically generated method it is (if any), and
     mark such methods also as "synthetic" in the JVM assembler code
   o split off the JVM-specific parser code (e.g., to add default
     constructors) into pjvm.pas

git-svn-id: branches/jvmbackend@18450 -
2011-08-20 08:00:50 +00:00