and add clone() method that calls inherited clone so that in case
of reflection lookup it will be found in this class rather than
getting an exception and having to search the parent class (will
be used in threadvar implementation)
git-svn-id: branches/jvmbackend@18809 -
code generator translation (as done by some ABIs, such as most x86-64
platforms and darwin/i386)
-> all regressions in jvmbackend branch for darwin/i386 fixed
git-svn-id: branches/jvmbackend@18806 -
oo_has_destructor is inherited from the parent class (because it
influences whether a VMT is required for TP-style objects),
so use separate oo_has_new_destructor flag instead
git-svn-id: branches/jvmbackend@18797 -
accidentally committed a long time ago (it was done to test the
generic hlcg conversion -- which in a sense was good, because it
just uncovered the bug fixed in svn trunk r18792, i.e. a bug
not specific to the hlcg conversion)
git-svn-id: branches/jvmbackend@18795 -
platforms after r18561 (newly introduced element-to-open-array type
conversion retains the value location on those platforms)
git-svn-id: branches/jvmbackend@18793 -
unicodestring = java.lang.String. The reason this was the default in
the past is that this was the first string type that was implemented,
and without it being the default most code involving string operations
would fail. Now the default strings types are the same as for other
targets
+ new {$modeswitch unicodestrings} directive, that when activated
*together* with {$h+},
1) changes char into an alias for widechar
2) changes string into an alias for unicodestring
3) changes the preferred string evaluation type (in case of uncertainty)
to unicodestring
{$modeswitch unicodestrings} with {$h-} does not change anything at all
regarding the string type (it still changes the char type)
+ new uuchar unit that redefines char as widechar, and which is automatically
included by the compiler if {$modeswitch unicodestrings} is enabled
git-svn-id: branches/jvmbackend@18781 -
resource compilation happens and that the standard FPC resource
helpers are not available. What happens is that all files specified
in {$r xxx} statements are packed together into an <appname>.jar
file, under the namespace "org.freepascal.rawresources". They
can be loaded using the java.lang.Class.getResource/getResourceAsStream()
api
git-svn-id: branches/jvmbackend@18776 -
a generalized version of the formal var/out/constref support (this
also fixes passing string[xyz] expressions to non-formal var/out/constref
parameters)
git-svn-id: branches/jvmbackend@18774 -
also handle non-formal parameters
* do not copy in the original value in handleformalcopyoutpara() if it's
an out parameter
git-svn-id: branches/jvmbackend@18772 -
can be added to typecast them to pchars)
* fixed array-of-char to ansistring conversion in case of zero-based
array and an embedded #0 (didn't stop at the embedded #0)
git-svn-id: branches/jvmbackend@18766 -
respectively to 0 and 255 (both generally require one memory load);
the setconstn complexity of 255 also caused the node cse to replace
them with temprefn in some cases, which wreaked havoc with the JVM
practice of determining whether in-expressions can be handled by
the generic code generator or not
git-svn-id: branches/jvmbackend@18756 -
variables, class/record fields and arrays with enumtype(0) on
creation, so that using them without explicitly initializing them
doesn't cause a null-pointer exception. If enumtype(0) is not a
valid enum, they are not initialized (and since they wouldn't have
a valid value on native targets either in that case, an exception
on use is acceptable)
git-svn-id: branches/jvmbackend@18755 -
constructors, inherited virtual class methods) when deciding which
overloaded version of a routine to call. Otherwise they can change
which variant is called compared to code on platforms where such
implicit methods are not added
git-svn-id: branches/jvmbackend@18752 -
valid_for_assign() if that routine returns true (in some cases,
it's used to simply check whether we could possibly put it on
the assignment side)
git-svn-id: branches/jvmbackend@18751 -
* added runerror number to JVM FpcRunTimeError exceptions
* enabled calling errorproc when a run time error occurs on the
JVM target
git-svn-id: branches/jvmbackend@18749 -
cpu64bitaddr is not defined rather than if cpu64bitalu is not
defined, because whether or not operations should be 64 bit by
default depends on cpu64bitaddr, and even if a cpu can perform
64 bit alu operations, 32 bit ones are likely faster
git-svn-id: branches/jvmbackend@18748 -
