o removed utf8string overload
o always ignore any code page information from the input, and interpret the
contents of the input directly as utf8-encoded bytes
* made utf8tostring() compatible with the JVM backend (mantis #29497)
git-svn-id: trunk@33159 -
parameter instead of immediately doing it in the constructor of the call
node, and then only create it if we actually need it.
It was previously created in the call node constructor because it needs to be
done before pass_1 (which is where it is actually used) due to pass_1 possibly
being performed in the context of inlining (and then a wrong self parameter
may be found, or none at all), and it was done unconditionally because at that
point we don't know yet whether or not a self parameter will be necessary (as
we haven't resolved the overloads/procdef yet).
The problem with this is that if we use the parentfpstruct way of handling
accesses to outer scope locals/parameters, we need to know all locals/
parameters that will be accessed from nested routines after typecheckpass,
otherwise we get crashes. The problem was that if a call to an RTL routine was
generated by the compiler in a routine nested inside a method during pass_1,
and this nested routine itself did not access self of the method (so self was
not added to its parentfpstruct during the typecheckpass), then the
unconditional reference to self when creating the call caused a compiler
crash (introduced in r30908)
git-svn-id: trunk@31197 -
class, which conflicts with java.lang.System in recent jdk javac's
(and we don't access any of the RTL classes explicitly in the
test program)
git-svn-id: trunk@30952 -
o only create an accessor wrapping the inherited accessor at a
potentially lower visibility level if the overriding property
itself does not specify a different accessor to use
o simplified code
o tests
git-svn-id: trunk@27954 -
Max Nazhalov) and use that code by default on the JVM target
* adapted JVM tests for the new str<->float code similar to how the
generic tests were adapted
git-svn-id: trunk@25954 -
-CTlowercaseprocstart
o convert all consecutive uppercase characters at the start to lowercase
instead of only the first one. Exception: if there is more than one
such character and the last one is followed by a lowercase character,
assume the last uppercase character belongs to the second word (like
in FPCIsGreat) and don't lowercase that one
+ test
git-svn-id: trunk@25845 -
when building the mangled name, because the latter can also be performed
when compiler another unit (and therefore if that other unit's setting
is different from that of the original unit, a wrong mangled name was
generated) + test for this case
git-svn-id: trunk@25388 -
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 -
so that code written according to Delphi coding standards can be compiled
into JVM bytecode with routine names conforming to JVM coding standards
git-svn-id: trunk@25385 -
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 -
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 -
beyond the 64kb per method limit (so that all tests can be compiled/run
with the -Co command line parameter to check that functionality against
false positives)
git-svn-id: trunk@22810 -
their nested tree already contains the load (subscriptn) for the variable
itself and there is no clean/easy way to avoid that in a completely
portable way in ncgnstld + test
git-svn-id: trunk@22519 -
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 -
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 -
to correctly handle non-pasbool types (can't just "not" their value),
and for Dalvik (a "not pasbool" became "xori 1", which turned the value
from a boolean into an integer as far as the Dalvik type checker was
concerned)
git-svn-id: branches/jvmbackend@20525 -
of the jdk15 unit in that case)
* adjusted testall.sh script so it can also be used to test class
files compiled for Android (still with the JVM though)
git-svn-id: branches/jvmbackend@19835 -
classes, interfaces, dynamic arrays, ...) as "array of JLObject",
but instead as an array of the actual pointed-to type. The reason
for the previous behaviour was mainly that the JVM threadvar
implementation internally stores all threadvars that are
such double pointer types into an "array of JLObject". Type casting
this array to e.g. an "array of array of byte" causes an exception
even if it only contains "array of byte" instances (since the outer
array type is different). This is now solved by first taking the
element of the array and then typecasting it to the destination
type (so dynarrbyte(arr[0]) instead of pdynarrbyte(arr)^[0]).
The reason for the new (more accurate) behaviour is because the
old one caused type errors in case a double pointer field was
internally created for the nestedfpstruct support (see added
test)
git-svn-id: branches/jvmbackend@19821 -
implicit pointer types into the nestedfpstruct, so that the original
parameter is properly changed when updated from inside nested routines
git-svn-id: branches/jvmbackend@19645 -
set the external name of the underlying class type to the internal name
instead of to an (invalid) empty string
git-svn-id: branches/jvmbackend@19555 -
routine at the same or a higher nesting level in case the current
nested routine's framepointer was not part of the nestedfpstruct
(because it doesn't have nested routines itself, or because those
don't access any data in parent routines) on targets with explicit
parentfpstruct management (JVM) + adapted test
git-svn-id: branches/jvmbackend@19164 -
o don't try to create .class files for generic types
o still generate all JVM-specific wrappers for generic types even though they
won't be written out, because when specializing all the defid's have to
match exactly
o add synthetic routine implementations after generating the specializations,
so that the synthetic routines for those specializations are also generated
(we don't specialize generic versions of the synthetic generic routines
because it's not easy or even always possible to create valid generic
versions of synthetic routines)
o Note: these are Pascal-style generics, not Java-style generics. The generic
types nor their specializations are usable from Java code (specializations
may become usable in the future)
git-svn-id: branches/jvmbackend@19047 -
the JVM target, and pos/insert/delete/val/str/uniquestring/setstring/
stringofchar/... are now also available for ansistrings on the JVM
target
git-svn-id: branches/jvmbackend@18906 -
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 -
jsstringh.inc -> use generic inc/sstrings.inc
* added a bunch of extra {$ifdef FPC_HAS_XXX} protections around
routines in inc/sstrings.inc and implemented those routines for
the JVM target in java/jsstrings.inc
* use the majority of the generic routine in sstrings.inc now also
for the JVM target! Only a few changes were needed:
o in a few places, calls to move() for copying shortstring->shortstring
or shortstring->chararray were replaced with calls to a new inline
helper that calls move() in the version in inc/sstrings.inc, and
JLSystem.arraycopt() in in the version in java/jsstrings.inc
o changed the currency argument to str() for the JVM target to constref
so its address can be taken (has to be typecasted to int64 without
changing the value), and similarly changed the temporary result
inside that routine to an array of 1 elements so the address can be
taken
o don't typecast the real value to a record type in str_real for the
JVM target, but work via an int64 instead to extract sign/mantissa/exp
o everything else compiled and worked as is!!
-> val, str, hexstr/octstr/binstr, delete, pos, insert, setstring and
comparetext now all work for shortstrings on the JVM target
git-svn-id: branches/jvmbackend@18836 -
