defcmp.pas:
+ add new function "def_is_related" which combines the "is_related" overloads of "tobjectdef", "trecorddef" and "tstringdef" (it returns "false" for other def types which is what "tdef.is_related" did)
* compare_defs_ext & compatible_childmethod_resultdef: change call from "x.is_related" to "def_is_related(x,...)"
symtype.pas, tdef:
- remove "is_related" method
symdef.pas:
- remove "is_related" in "tobjectdef", "trecorddef" and "tstringdef"
* tobjectdef.needs_inittable: for checking whether a Corba interface somehow inherits from a IInterface don't use "is_related" anymore (we want to avoid the dependency after all), but mimic the necessary functionality of "def_is_related"
htypechk.pas, nadd.pas, ncal.pas, ncnv.pas, ngtcon.pas, nld.pas, optvirt.pas, pdecobj.pas, pdecvar.pas, pexpr.pas, pgenutil.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
symtable.pas
+ use unit defcmp
* change call from "x.is_related" to "def_is_related(x,...)"
jvm/njvmcnv.pas, jvm/njvmflw.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
git-svn-id: trunk@25847 -
cgobj.pas, tcg:
* g_save_registers: add the amount of used address registers to size as well
* g_save_registers: save all used address registers
* g_restore_registers: restore all stored address registers
m68k/cpubase.pas:
* rename saved_standard_address_registers to saved_address_registers
all other platform's cpubase.{inc,pas} (except alpha, ia64 and vis which are not up to date):
* add a saved_address_registers variable with one entry of RS_INVALID
At least a "make fullcycle" did complete.
git-svn-id: trunk@25664 -
(we previously internally generated assigned(unicode/ansistring) nodes,
which now cause typecheck errors because there is no special assigned
handling anymore)
git-svn-id: trunk@25557 -
that may trigger JVM bytecode verification errors if they are used
before they are initialised (this includes passing them as a "var"
parameter) + test
* sorted -CT parameters alphabetically and alligned them
git-svn-id: trunk@25387 -
a property in a child class has a higher visibility than the getter/
setter), ensure that we call the inherited method and not the method
itself (causing a stack overflow due to infinite recursion)
git-svn-id: trunk@25223 -
have to wrap an existing (g|s)etter that was marked as "abstract" (don't
mark the helper also as abstract, sicnce it contains code)
git-svn-id: trunk@23545 -
its property in case the visibility of the property is higher than
that of the getter/setter (on the JVM target when automatically
generating getters/setters)
git-svn-id: trunk@23523 -
that the type of the parameters can be determined automatically
o added compilerproc declarations for all helpers called in the compiler
via their assembler name, so we can look up the corresponding procdef
git-svn-id: trunk@23325 -
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 -
like field reordering (possible problems cracker classes) or using ebp as normal register (broken
stack traces from dump_stack)
+ niln is also valid in a cse domain
* parameters passed by reference shall have a complexity >1
* load nodes from outer scopes shall have a complexity >1
* better cse debugging
+ more node types added to cse
* consider parameters passed by reference in cse
* take care of cse in parameters in simple cases
git-svn-id: trunk@22050 -
used across multiple levels of inheritance such as on MIPS (and the code
has to be reusable for a_call_ref/reeg in the future anyway)
git-svn-id: trunk@21906 -
defines INTERNAL_BACKTRACE (which assumes get_frame to be internal rather
than a system unit procedure)
* changed fpc_assert() declaration for jvm to be the same as for other
targets, so the same code can be used to call it in ninl now that's
called from the first pass
git-svn-id: trunk@21903 -
result location (NR_FUNCTION_RESULT_REG is not valid on all platforms)
o this requires passing the forced function result type (if any) to this
method
o a generic, basic thlcg.a_call_name() is now available that sets the
function result location; can be called by descendants
* the availability under all circumstances of the correct function return
type enables g_call_system_proc() on the JVM platform to now determine
by itself how many stack slots are removed by the call -> do so, instead
of manually counting them (or forgetting to do so and messing up the
maximum evaluation stack height calculations)
git-svn-id: trunk@21862 -
with the enum instance corresponding to ordinal 0 in JVM constructors,
because a virtual method called by a parent constructor may already
have assigned a different value (see tests/test/jvm/tenum2.pp). This
will result in null pointer exceptions when using such fields without
first explicitly assigning a value to them though.
The old behaviour can be restored with the new -CTenumfieldinit command
line parameter
git-svn-id: trunk@21736 -
getintparaloc + adapted all call sites of getintparaloc. This
led to a number of additional, related changes:
o corrected the type information for some getintparaloc parameters
o don't allocate some intparalocs in cases they aren't used
o changed "const tvardata" parameter into "constref tvardata" for
fpc_variant_copy_overwrite to make pass-by-reference semantics
explicit
o moved a number of routines that now have to call find_system_type()
from cgobj to hlcgobj so that cgobj doesn't have to start depending
on the symtable unit
o added versions of the cpureg alloc/dealloc methods to hlcgobj that
call through to their cgobj counter parts, so we can call save/restore
the cpu registers before/after calling system helpers from hlcgobj
(not implemented in hlcgobj itself, because all basic register
allocator functionality is still part of cgobj/cgcpu)
git-svn-id: trunk@21696 -
RS_INVALID superregister (instead of sometimes RS_NO and sometimes
RS_INVALID)
* check for RS_INVALID in tcg.g_save_registers() and ignore such entries
git-svn-id: trunk@21622 -
methods that don't have to be implemented by targets using the high
level code generator, with dummy implementations that raise an internal
error (to remove warnings about instantiating classes with abstract
methods)
* let the JVM tcg descendent derive from this new thlbasecgcpu class
git-svn-id: trunk@21098 -
ansistrings are represented by nil
* fixed type conversion of constant empty ansistring/unicodestring to
pchar/pwidechar on the JVM target
git-svn-id: branches/jvmbackend@21055 -
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 -
