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 -
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 -
