* always register vmt defs (so they get written to the ppu) in case of llvm,
because it may need this def in case a method from a class defined in the
implementation of unit gets called from an inlined routine that gets
inlined in another unit (normally that vmt def would not get written to
the ppu file, as it can't be referenced from the interface and it's also
not necessarily directly referenced from the inline routine's nodes)
(fixes sdo_dataobject compilation with LLVM after enabling cross-unit
inlining of methods accessing static symbol table symbols)
git-svn-id: trunk@42342 -
overrides but before generating the VMT, so that these hidden parameters
are part of the procdefs stored in the VMT (fixes some LLVM type errors
after r41716)
git-svn-id: trunk@41884 -
encountering a method with the correct name that does not have the
"overload" directive (same logic as when looking for a call candidate,
to avoid errors when using a Pascal-level wrapper to call interface
methods, and Delphi-compatible since it always required "overload" for
overloaded methods)
o also catches calling convention mismatches like in webtbs/tw27349
git-svn-id: trunk@40683 -
type-safe way (for LLVM, and also internal consistency checking between
the VMT as generated in nobj.pas and ncgvmt.pas)
o also converted the VMT validity checking to the node level
git-svn-id: trunk@30950 -
This improves compiling speed a bit (two iterations over symtables replaced by one, code generator is created once per unit rather than once per class).
In perspective it makes possible to reduce amount of generated smartlink sections and global labels.
git-svn-id: trunk@24269 -
raised because it was automatically raised in the parent class (can happen
for the JVM target when letting the compiler generate getters/setters for
properties)
git-svn-id: trunk@23522 -
Only referencing data labels from code should change "GOT is needed" property. Writing data labels or referencing them from data should have no effect on it.
git-svn-id: trunk@23363 -
JVM target, since Java bytecode itself has no support for properties and
hence exposing properties to external Java code can only be done through
getters/setters. Use the new parameters to do so:
-CTautogetterprefix=XXX
-CTautosetterprefix=YYY
The getter/setter will get the same visibility as the property. If a
getter/setter with the same naming convention was already specified for a
property and this getter/setter is declared in the same class as the
property, then the visibility of this existing getter/setter is
modified and no new routine is generated.
Newly generated getters/setters are virtual methods, because that is
the only way in Java bytecode to allow redefining these getters/setters
in child classes. However, that also means that using these switches can
change the behvaviour of code, since normally the used property definition
is only determined by the declared type of its associated class instance,
and not by the actual instance type. The compiler will therefore warn when
such an automatically generated getter/setter is overridden by another
automatically generated getter/setter in a child class.
git-svn-id: trunk@22959 -
* only check whether the message identifier of an Objective-C method
matches the one from a method with the same name in a parent class
if the parameters match (todo: should be refined to "if the
encoded Objective-C selector names match")
git-svn-id: trunk@22373 -
method by one with a lower visibility, because calling the overriding
method results in a java.lang.AbstractMethodError in that case
git-svn-id: trunk@21839 -
to 0 or 1 (section alignment <> alignment of individual data
elements in section on some platforms, such as AIX)
* set constalignmin and varalignmin to 8 bytes for AIX/ppc64
git-svn-id: trunk@21044 -
o support for the new codepage-aware ansistrings in the jvm branch
o empty ansistrings are now always represented by a nil pointer rather than
by an empty string, because an empty string also has a code page which
can confuse code (although this will make ansistrings harder to use
in Java code)
o more string helpers code shared between the general and jvm rtl
o support for indexbyte/word in the jvm rtl (warning: first parameter
is an open array rather than an untyped parameter there, so
indexchar(pcharvar^,10,0) will be equivalent to
indexchar[pcharvar^],10,0) there, which is different from what is
intended; changing it to an untyped parameter wouldn't help though)
o default() support is not yet complete
o calling fpcres is currently broken due to limitations in
sysutils.executeprocess() regarding handling unix quoting and
the compiler using the same command lines for scripts and directly
calling external programs
o compiling the Java compiler currently requires adding ALLOW_WARNINGS=1
to the make command line
git-svn-id: branches/jvmbackend@20887 -
* Pass target asmlist as parameter to genpublishedmethodstable and generate_field_table.
* Omit field table if there are no published fields (Delphi compatible).
git-svn-id: trunk@20310 -
- removed empty destructors, overriding destructor without calling inherited is incorrect (although harmless here).
* pass target asmlist as parameter to message table generation procedures, instead of using global variables.
git-svn-id: trunk@20303 -
or published, because interface methods are always public and
hence mapping them to a private/protected method increases the
visibility of the underlying method (error on JVM target because
the JVM doesn't like that, warning on other platforms)
git-svn-id: branches/jvmbackend@19156 -
in that case if an "override" directive is missing but we interpret
the declaration as an "override" anyway, make sure to replace the vmtpd
with the overriding definition or child classes will keep seeing
the abstract method in the base class and keep decreasing their abstract
method count below zero
* only decrease the abstract method count in case we're not processing
category methods
git-svn-id: branches/jvmbackend@18923 -
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 -
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 -
