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 -
to and returning them from sub routines, in order to follow the JVM
specs to the letter (not checked by the JVM bytecode verifiers, but
checked by the Android DEX verifier)
* -> also zero-extend them again at the caller side after returning
from such a function
git-svn-id: branches/jvmbackend@18919 -
required based on the source/destination sizes (like in
a_load_reg_reg(), a_load_ref_reg() and a_load_ref_ref())
git-svn-id: branches/jvmbackend@18918 -
targets:
o initialize managed temps that are passed as var-parameters to the
dests-parameter of the concat routines, because they will be read and
stored in the var-parameter array (they are finalized and hence work
fine on native targets, but finalization is a nop on the JVM target)
o do not take the shortcut of comparing with nil when checking for an
empty ansi/unicodestring on managed VM targets
git-svn-id: branches/jvmbackend@18909 -
complex parameters passed to inlined routines on the JVM target, because
it is not possible to take the address of any kind of node on the JVM
target (temp-reference nodes work for any kind of LOC_(C)REFERENCE, but
are currently only implemented for the JVM platform)
git-svn-id: branches/jvmbackend@18905 -
val/str for enums for now) for the JVM target: insert/delete/pos/...
* use generic unicodestring helper routines where possible for the JVM
target (not that many as for shortstrings since unicodestring is
handled using java.lang.String)
+ complete widestring manager implementation for the JVM target. It uses
a class with virtual methods rather than a record with function pointers
for speed reasons though (since no existing widestring manager will be
compatible anyway, that shouldn't cause any problems)
git-svn-id: branches/jvmbackend@18882 -
consistency with other helpers
+ added lowercase(unicodechar) and lowercase(unicodestring) overloads (for some
reason only upcase() existed for them)
git-svn-id: branches/jvmbackend@18881 -
their address is taken if they are normally passed by reference (since then
taking this address in the callee normally also gets the address of the
original variable rather than of a copy)
git-svn-id: branches/jvmbackend@18834 -
resultdef for internally generated method calls
* force the resulttype of methods used to build non-unicode string
constants on the JVM platform to the stringconstn's resultdef
git-svn-id: branches/jvmbackend@18832 -
overloads for several routines that conflict on the JVM target because
their parameter types are encoded into the same signature simply as
external, e.g. swap, swapendian, odd, sqr, ...)
git-svn-id: branches/jvmbackend@18823 -
as far as Java is concerned, they're now all arrays of JLObject.
When loading a value from them, we typecast the loaded value
to the appropriate type. This allows typecasting one pointer
type to another without getting verification errors (since an
"array of JLObject" is not compatible with "array of JLString")
- no longer allow dereferencing untyped pointers on the JVM
target, since that always results in invalid bytecode
git-svn-id: branches/jvmbackend@18819 -
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 -
