with wrapper calls, because the parameter nodes are already bound to the
paravarsyms of the current procdef so simply replacing the procsym and
procdef is not enough
git-svn-id: branches/jvmbackend@18739 -
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 -
types involved to determine whether or not the comparison is
unsigned (they don't always match due to bugs in the compiler,
and the sign of the comparison operation is what's used in
other code generators too)
git-svn-id: branches/jvmbackend@18734 -
* catch java.lang.NoSuchMethodException exceptions when resolving a procvar,
because java.lang.Class.getDeclaredMethod() only searches that particular
class itself and not its parents -> in case we get the address of a method
that's not overridden in the current class, also search the parent classes
git-svn-id: branches/jvmbackend@18730 -
in the JVM means "accessible to subclasses *and* to classes in the same
package" (and all classes in the same unit are by definition also in the
same package) -- before, such fields were declared as "package" which means
that they could not be accessed by subclasses in other packages
git-svn-id: branches/jvmbackend@18728 -
type is a forward-defined class whose full definition hasn't been parsed
yet and if the full definition changes the external name of the class
git-svn-id: branches/jvmbackend@18727 -
methods as "virtual" anymore (since they're not virtual, and the
compiler now handles virtual class methods differently)
git-svn-id: branches/jvmbackend@18725 -
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 -
(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 -
be reused elsewhere
* moved check_hints() from htypechk to symsym (so it can be called
from nutils, and it's also more about symbols than about types)
git-svn-id: branches/jvmbackend@18722 -
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 -
since virtual class methods are handled differently from regular ones and
the JDK contains several (non-virtual, since Java does not support virtual
class methods) final class methods
git-svn-id: branches/jvmbackend@18720 -
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 -
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 -
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 -
by a non-virtual classmethod/constructor on the JVM target, because they
would also be picked up by the dynamic dispatch
git-svn-id: branches/jvmbackend@18713 -
work because you cannot start new inheritance trees, it can work under some
circumstances if the parameters are not exact. In case there is a problem,
this will be detected later by TVMTBuilder.is_new_vmt_entry().
git-svn-id: branches/jvmbackend@18711 -
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 -
(so that you can override a method in a child class with one that
returns a descendent of the original return type -- since the JVM
will always select the version with the most specific return type,
that even corresponds perfectly to standard JVM behaviour)
git-svn-id: branches/jvmbackend@18706 -
o also save/restore orgpattern (and restore pattern) when saving/restoring
the scanner state, since it's used by e.g. the _INTCONST token
o also bail out on _CWCHAR and _CWSTRING tokens, since that requires saving
the scanner widestring state
git-svn-id: branches/jvmbackend@18705 -
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 -
ShortStringClass.FpcDeepCopy (can happen when copying value
parameters like string[4] into local storage in case a string
longer than 4 characters was passed)
* create chararray of the correct maximum length when constructing
a chararray from a constant string
* don't pass invalid ranges to JLArrays.fill() when padding a
chararray after filling it using the contents of shortstring
git-svn-id: branches/jvmbackend@18701 -
on the caller side whether it's a normal or class method that we are
calling, add the self-class parameter inside the invoke method if
necessary (by simply counting the number of parameters and inserting
it if we're one short)
git-svn-id: branches/jvmbackend@18699 -
their initialization can cause races between the unit they are declared
in and the class constructor they are initialized in (even if both
would be moved to the unit initialization code, a class constructor
using the set constant could run before the unit initialization code has
run)
git-svn-id: branches/jvmbackend@18698 -
JVM target, because that's the only way to guarantee their semantics on
that platform (see comments in pdecobj)
* allow starting new inheritance trees (which is the same as adding a new
non-virtual method as of this revision) on the JVM target in case the
parameters of the new routine match the old one, but the complete mangled
name does not (because then the JVM won't consider them to be the same
either -> Pascal semantics are matched)
git-svn-id: branches/jvmbackend@18695 -
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 -
