involved and the classes are not exactly equal (but one is a child of the
other): we have to look up the real class definition first in those cases
git-svn-id: trunk@20622 -
class before its VMT has been built, because that's the process that looks
for inherited abstract methods that are overridden -> instead use a new
synthetic method kind (tsk_callthrough_nonabstract) that will call
through to another method (in this case a constructor) if the owning
class does not contain any abstract methods, and generates an
empty routine otherwise
git-svn-id: branches/jvmbackend@20589 -
(= Android 4.0) java headers: java.*, javax.*, org.*, junit.*, android.*).
The RTL can also be used to target earlier versions of the Android
platform, but you manually have to take care of not using APIs that
weren't available yet. Adding separate units for separate platform
versions would only partly solve the problem, because some of the
classes used inside the system unit have also changed across
versions.
Use -Tandroid while compiling to select the Android OS as target
platform.
git-svn-id: branches/jvmbackend@19830 -
- don't pass CP_NONE encoding to internal functions. They handled it as 0 encoding. This will optimize the generated code a bit.
- convert all king of string/char/pchar constants to local ansistring def if they needs to be passed to rawbytestring type. They should not get a CP_NONE codepage (delphi compatible)
- don't convert left and right arguments of string concatenation to ansistring type if they are already ansistrings but with different codepage - RTL already handles different codepages in concat routine
- fix resultdef for ansistring concatenations inside assignments - return def of left assignment operand if it is already ansistring - this reduces amount of unneeded condepage conversions since concat functions can return result in any desired codepage
rtl: remove CP_NONE comparisions from most of RTL functions, replace 0 constant with CP_ACP
tests: add test to check various conversions to RawByteString type
git-svn-id: trunk@19519 -
- add helper function getansistringcodepage which returns explicitly set codepage or 0 in other case
- add helper function getansistringdef which return a def with explicitly set codepage or cansistringtype in other case
- change tstoreddef.createnai constructor to allow set codepage in constructor
- don't convert string constants to rawbytestring. if string constant already has a codepage - preserve it or convert to ansistring codepage (delphi compatible)
- don't perform string conversion from ansistring to strings with explicitly set codepage (by directive or by compiler switch) and vice versa (delphi compatible)
+ test which covers most of the cases
git-svn-id: trunk@19510 -
* eliminate warnings in compiler (i386 & i368->x86_64) and minor refactorings
- comment out unused vars and types
- comment out unneeded comparisons (Longword <=> 0)
- suppress some "comparison always true|false" warnings
- tweak visiblity sections
git-svn-id: trunk@19385 -
U compiler\pdecsub.pas
U compiler\symdef.pas
U compiler\pdecobj.pas
U compiler\htypechk.pas
U compiler\ncal.pas
U compiler\symtable.pas
--- Recording mergeinfo for merge of r19281 into '.':
U .
--- Merging r19282 into '.':
A tests\webtbf\tw19975.pp
--- Recording mergeinfo for merge of r19282 into '.':
G .
git-svn-id: trunk@19343 -
are used to implement procvar types, and add a constructor to the procvar
types that accept an instance implementing this interface -> much easier
and more natural to use procvar types from Java code
git-svn-id: branches/jvmbackend@19216 -
var-parameters on the JVM target for changes to the value passed
as var-parameter during the function call (because they are handled
via copy-in/copy-out, this may indicate unexpected bahviour later on).
out-parameters are checked in the same way, except if the out-parameter
is a local variable because then reading it before the call may result
in a bytecode verification error (since the variable may not yet be
initialized)
git-svn-id: branches/jvmbackend@19153 -
*In normal procedure "var" and "out" RawByteString parameters does not accept other string types. Procedures with
"compilerproc" directive or the newly added "rtlproc" directive accept that. Please note that it is up to the
procedure coder to ensure the correctness of the code page in that case. The new directive is needed to handle
the RTL procedures/functions that are not marked as "compilerproc" such as "UniqueString", "Insert" and "Delete".
*Correct "fpc_ansistr_concat" to handle code page correctly.
*Default "ansitring" type is now created with code page set to "0" instead of "65535". Before that change it was
impossible to distinguish a "RawByteString" with the default "ansistring". At runtime "ansistring" variable'code
page is set to DefaultSystemCodePage
*UniqueString flavor of "SetLength" has been updated to release memory when shrinked to at least 50%, like ansitring
does.
git-svn-id: trunk@19118 -
+ support parsing of strings with code page specification
+ added encoding and elementsize field to ansi- and unicodestring records
+ some basic rtl support routines for encoding aware strings
+ DefaultSystemCodePage
+ DefaultUnicodeCodePage
+ ppu writing/loading of code page aware strings
git-svn-id: trunk@19080 -
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 -
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 -
on the JVM target (at the Pascal level), by automatically generating
getters/setters of the same visibility as the property that are used
instead of directly accessing the fields when translating the property
git-svn-id: branches/jvmbackend@18724 -
support those natively, so they are emulated via the procvar infrastructure
(and hence not very fast). Could probably be optimized somewhat by adding
a cache (hashmap of procvars) to the class hierarchies, maybe in the
future.
git-svn-id: branches/jvmbackend@18704 -
o every porocedural variable type is represented by a class with one
public "invoke" method whose signature matches the signature of the
procvar
o internally, dispatching happens via java.lang.reflect.Method.invoke().
WARNING: while this allows calling private/protected or other methods
that are normally not accessible from another context, a security
manger can override this. If such a security manager is installed,
most procvars will cause security exceptions
o such dispatching also requires that all arguments are wrapped, but
that's done in the compiler-generated body of the invoke method,
so that procvars can also be called conveniently from Java code
o typecasting between a procedure of object and tmethod is supported,
as well as Delphi-style replacing of only the method pointer via
@procvar1=@procvar2.
o nested procvars are not yet supported, but most of the basic
infrastructure for them is already present
* all units/programs now get an internal __FPC_JVM_Module_Class_Alias$
type when compiled for the JVM target, which is an "external" class
that maps to the unit name. This is required to look up the
JLRMethod instances for regular functions/procedures
+ new tabstractprocdef.copyas() method that allows to create a procvar
from a procdef and vice versa
git-svn-id: branches/jvmbackend@18690 -
o primitive types are first boxed
o the parameter is passed inside an array of one class instance
o changing the parameter inside the routine (by assigning a value to it
like in Delphi.NET and different from regular Pascal code) will replace
this class instance (again boxing the value if required)
o on return, the class instance is extracted, unboxed if required, and
assigned back to the original location
o formal const parameters are handled without the extra array indirection,
since they cannot be changed
TODO: while writing tjvmcallparanode.handleformalcopyoutpara() I forgot that
calling getcopy on ttemprefnodes whose ttempcreatenode hasn't been copied
yet works fine, so that code is more complex than needed. Still have to
fix.
git-svn-id: branches/jvmbackend@18675 -
copying that over the old one into calling a dedicated fpcInitializeRec()
method that initializes the required fields. The reason is that this
initialization is performed for out-parameters, and the fpcDeepCopy()
method (used to copy one instance over another) has an out-parameter
-> infinite loop
git-svn-id: branches/jvmbackend@18674 -
o sets of enums are handled as JUEnumSet instances, others as JUBitSet
derivatives (both smallsets and varsets, to make interoperability with
Java easier)
o special handling of set constants: these have to be constructed at run
time. In case of constants in the code, create an internal constsym to
represent them. These and regular constsyms are then aliased by an
another internal staticvarsym that is used to initialise them in the
unit initialisation code.
o until they are constructed at run time, set constants are encoded as
constant Java strings (with the characters containing the set bits)
o hlcgobj conversion of tcginnode.pass_generate_code() for the genjumps
part (that's the only part of the generic code that's used by the JVM
target)
o as far as explicit typecasting support is concerned, currently the
following ones are supported (both from/to setdefs): ordinal types,
enums, any other set types (whose size is the same on native targets)
o enum setdefs also emit signatures
o overloading routines for different ordinal set types, or for different
enum set types, is not supported on the JVM target
git-svn-id: branches/jvmbackend@18662 -
* use this counter to mark classes containing abstract methods as
"abstract" in the bytecode per the JVM spec
* also use the counter to short-circuit printing of all abstract
methods in a class when creating a new instance (we build the list
of abstract methods every time a new instance is created, which is
a waste of time if there are none in the first place)
git-svn-id: branches/jvmbackend@18635 -
property, generate a wrapper with the same visibility as the property
that calls through to the original getter/setter (JVM target only:
ensures that the JVM verifier doesn't complain about calling methods
that are not visible to the current class when using such properties
from other units/classes)
git-svn-id: branches/jvmbackend@18632 -
JDK class-style enums rather than plain ordinals like in Pascal
o for Pascal code, nothing changes, except that for the JVM target
you can always typecast any enum into a class instance (to interface
with the JDK)
o to Java programs, FPC enums look exactly like Java enum types
git-svn-id: branches/jvmbackend@18620 -
o these classes get an "enum" flag in the class files
o these classes get a class field (whose type is that same enum
class) per enum in the type, which also gets the "enum" flag
o those class fields are initialised in the class constructor
with the name of the enum and their order in the declaration
o if the enum has jumps in FPC (lowest value is not 0, or not
all values are contiguous), then we add an extra field
to hold the FPC ordinal value of the enum
o these classes get a class field valled $VALUES that contains
a reference to the aforementioned class fields in order of
declaration (= ordinal->instance mapping, JDK-mandated)
o apart from the JDK-mandated instance methods (values, valueOf),
also add FPCOrdinal (returns FPC ordinal value; same as order
of declaration in case of no jumps) instance method and FPCValueOf
(returns enum corresponding to FPC ordinal value) static class
method
o the mapping between FPC ordinals and enum instances in case of
jumps is stored in a hashmap whose size is the next prime number
greater or equal than the number of enum elements
o moved several extra JDK types to the system unit for the enum
support, and for future boxing and Java set support
o several new synthetic method identifiers to generate the enum class
methods/constructor/class constructor
o enums with jumps are ordered by FPC ordinal value in the JVM
$VALUES array so that the java.lang.Enum.doCompare() method
will properly compare them
git-svn-id: branches/jvmbackend@18616 -
mangled name handling ansistring rather than pshortstring based (required
for JVM target; little effect on speed, some extra memory usage)
git-svn-id: branches/jvmbackend@18597 -
o since the JVM target has no stack/framepointer that can be passed
on to nested routines, all local variables and parameters accessed
from nested routines are grouped into a local record whose address
is passed to nested routines. The same technique is also required
for LLVM in the future
git-svn-id: branches/jvmbackend@18588 -
creating procdef's JVM mangled name, because this situation can also
arise in case there's a simple error in the source code
git-svn-id: branches/jvmbackend@18586 -
(non-dynamic arrays, records, shortstrings)
- removed the ability to typecast such types directly into related class
types, you have to use the @-operator first now to get a pointer to
the type
o updated the RTL and internal compiler code to properly use this
new convention
o allowed removing several special cases from
tjvmtypeconvnode.target_specific_general_typeconv(), and that
method can probably be removed completely over time
* no longer give compile time errors for pointer-related typecasts that
will fail at run time, because the checking was too complex and could
be worked around via actual pointer typecasts anyway
* removed some unnecessary checkcast operations (for shortstring/
shortstringclass)
git-svn-id: branches/jvmbackend@18574 -
o support for ansistring constants. It's done via a detour because the
JVM only supports UTF-16 string constants (no array of byte or anything
like that): store every ansicharacter in the lower 8 bits of an
UTF-16 constant string, and at run time copy the characters to an
ansistring. The alternative is to generate code that stores every
character separately to an array.
o the base ansistring support is implemented in a class called
AnsistringClass, and an ansistring is simply an instance of this
class under the hood
o the compiler currently does generate nil pointers as empty
ansistrings unlike for unicodestrings, where we always
explicitly generate an empty string. The reason is that
unicodestrings are the same as JLString and hence common
for Java interoperation, while ansistrings are unlikely to
be used in interaction with external Java code
* fixed indentation
git-svn-id: branches/jvmbackend@18562 -
are JVM annotations used by Java's generics support. They cannot be used
for FPC's generics support, but they are useful in other cases
* emit classrefdefs as java.lang.Class, with a signature annotation that
indicates which class they actually refer to
git-svn-id: branches/jvmbackend@18534 -
typeconversion handling
+ support for class reference types in the JVM (although without class virtual
methods, they're not that useful)
git-svn-id: branches/jvmbackend@18516 -
current class, since constructors are not automatically inherited in
Java
o tprocdef.getcopy() implementation, which returns an (unfinished) copy
of a tprocdef. Finalise by calling symcreat.finish_copied_procdef()
o made it possible to specify an existing procdef as argument to
read_proc(), in which case it won't try to parse a procedure declaration,
but only a body and associate it with the passed procdef. This is
required for the inherited constructor support, since we cannot generate
a textual representation of inherited constructors that is guaranteed to
parse in the context of the current unit (e.g., if they use types from
a unit that is not in the uses clause of the current unit)
o folded tprocsym.find_procdef_bypara_no_rettype() into
Tprocsym.Find_procdef_bypara, by interpreting specifying nil as
retdef as not having to check the return def (required to compare
parent constructors with child constructors to see whether they
match, since the returndef will always be the current class type)
git-svn-id: branches/jvmbackend@18488 -
assignment-nodes. For global typed constants and typed constants/
local variable initialisers in regular functions/procedurs, the
assignments are performed in the unit initialisation code. For
those in object/record definitions and their methods, it's done
in the class constructor. Since we may not yet have parsed all
method implementations when the class constructor is parsed, part
of these may be initialised in a helper routine called from the
class constructor. The ones known when the class constructor is
parsed are inited there, because the ones marked as "final" and
declared as static class fields must be initialised in the class
constructor for Java
o new set systems_typed_constants_node_init in systems unit that
indicates that a target uses node trees to initialise typed consts
instead of an initialised data section
o mark typed constants in {$j-} mode as "final" for JVM
o mangle the name of staticvarsyms inside localtables a bit to avoid
name clashes (only with procedure names for now, no parameters yet
so can still cause problems with overloaded routines)
o after a routine has been parsed, it is now processed by
cnodeutils.wrap_proc_body(), which can add extra nodes before code
generation (used for injected the typed constant node trees)
git-svn-id: branches/jvmbackend@18475 -
in a single statement, to be added later)
o the unicodestrings are internally simply java.lang.String instances
o at the language level, the unicodestrings are assignment-compatible
with java.lang.String
o constant strings can be implicitly converted to java.lang.String
o since java.lang.String is immutable, in particular changing a
single character in a string is extremely inefficient. This could
be solved by letting unicodestring map to java.lang.StringBuilder,
but that would make integration with plain Java code harder
git-svn-id: branches/jvmbackend@18470 -
JLObject with the method "Free" and a virtual destructor "Destroy"
(and Free is automatically called from the "finalize" method,
which in turn is called by the JVM when the instance is collected;
note that there is no final collection before the JVM shuts down,
so it may never be called if you don't call Free explicitly yourself)
* if you don't specify an explicit ancestor for a Java class, set
the parent to TObject instead of to JLObject (for better compatibility
with regular Pascal code)
git-svn-id: branches/jvmbackend@18466 -
o initialise class vars that need initialisations (records, arrays) in
class constructors
o treat class constructors as having a "void" resultdef rather than the
class type for JVM (maybe has to be done in general?)
o make it possible to specify pno_noleadingdollar to
tprocdef.customprocname() so it can be used for class constructors
(their name is lower cased because it mustn't conflict with other
identifiers, since their name doesn't matter anyway)
o added tsk_empty synthetic procdef kind which, as the name implies,
generates an empty body (for class generated constructors)
+ auto-generate class constructors in case a class has class vars that
need initialisation
git-svn-id: branches/jvmbackend@18462 -
and initialise global variables that are wrapped (records, arrays)
in those sections
o check whether pd.localst is assigned in dbgjasm, because it's
not for the unit initialisation routine
o moved insertbssdata() from ncgutil to ngenutil and override it
njvmutil (it does nothing in the latter, since global variables
are added as fields to the class representing the unit; the
initialisation is done in gen_initialize_code() in thlcgjvm)
o added force_init() and force_final() methods to ngenutil, so
that targets can force init/final routines separate from the
regular managed types infrastructure (used by JVM for forcing
an init section in case of records/arrays)
git-svn-id: branches/jvmbackend@18460 -
implemented via classes, all descending from system.FpcBaseRecordType
(records are also considered to be "related" to system.FpcBaseRecordType
on the JVM target)
* several routines are auto-generated for all record-classes: apart
from a default constructor (if there is none), also clone (which
returns a new instance containing a deep copy of the current
instance) and deepCopy (which copies all fields of one instance
into another one)
o added new field "synthetickind" to tprocdef that indicates what
kind of synthetically generated method it is (if any), and
mark such methods also as "synthetic" in the JVM assembler code
o split off the JVM-specific parser code (e.g., to add default
constructors) into pjvm.pas
git-svn-id: branches/jvmbackend@18450 -
from tobjectdef to tabstractrecorddef, since records are implemented
via Java classes on the JVM target (and hence have an associated
package name, and we have to be able to generate their JVM-style
mangled name)
* adapted ppudump to this change
git-svn-id: branches/jvmbackend@18449 -
shortstrings to prevent cut-offs
+ ReplaceCase() ansistring overload in cutils to support the above
* always use the fully qualified name in case of nested types inside
the parameter lists of procdefs
* put extra information about array parameters between {} so they
can be passed back into the parser
git-svn-id: branches/jvmbackend@18431 -
artificially generated stuff rather than directly working with defs/syms
problems
o scanner state saving/restoring, and avoiding problems in case of
errors in the injected strings
o in case of the actual application (adding overriding constructors):
the parameters may be of types not visible in the current unit to
newly written code -> can't just use the scanner...
git-svn-id: branches/jvmbackend@18427 -
a new customprocname() method and tprocnameoption flags (add parameter
names, add "function"/"procedure", add name of owning struct or not,
don't add the "class" prefix for class methods)
Reason: for internal use by the compiler so it can output the procdef
into something that can be fed back to the parser for reuse (seems
easier than manually constructing a new procdef, or duplicating it
inside of another objectdef)
git-svn-id: branches/jvmbackend@18426 -
o always create exceptvarsym entry for on-nodes (on all targets) to remove
some special cases when an unnamed exception was caught
o the JVM tryfinally node generates the finally code twice: once for the
case where no exception occurs, and once when it does occur. The reason
is that the JVM's static bytecode verification otherwise cannot prove
that we will only reraise the caught exception when we caught one in
the first place (the old "jsr" opcode to de-duplicate finally code
is no longer used in JDK 1.6 because it suffered from the same problem,
see Sun Java bug
http://webcache.googleusercontent.com/search?q=cache:ZJFtvxuyhfMJ:bugs.sun.com/bugdatabase/view_bug.do%3Fbug_id%3D6491544 )
git-svn-id: branches/jvmbackend@18387 -
o tobjectdef.jvm_full_typename() now gets an extra parameter to determine
whether or not the package name should be prepended, so it can be easily
used to generate the name of the .j file and of the class name inside it
git-svn-id: branches/jvmbackend@18384 -
o hlcgobj support in tcgsubscriptnode.pass_2 for JVM-required functionality
o slightly different handling for class fields for the JVM than for other
platforms: instead of adding a unit-level staticvarsym with a hidden name,
rename the original (unused) field and add the staticvarsym with the original
name to the object symtable. This is required because the JVM code generator
has to know the class the field belongs to, as well as its real name
o moved tprocdef.makejvmmangledcallname() functionality mostly to
jvmdef.jvmaddtypeownerprefix() because it's also required for mangling
field symbol names
* changed the interface of jvmdef from ansistring to shortstring because
all of its results are also used in shortstring contexts (and they're
unlikely to overflow the shortstring limit)
* "protected", "private" (without strict) and implementation-only symbols
now get "package" visibility instead of "public" visibility
git-svn-id: branches/jvmbackend@18349 -
since the definition-specific adorning of JVM mangled names is Jasmin-
specific, and such code has no place in symdef
* moved code to adorn JVM mangled names for Jasmin definitions to agjasmin
git-svn-id: branches/jvmbackend@18346 -
name of a Java class (package/procname), extracted from jvmdef
* several fixes to jvmmangledname (po_has_importdll only applies to
unit-level procedures, replace incomplete mangling of class type names
with call to jvm_full_typename()
git-svn-id: branches/jvmbackend@18326 -
o support formal external definitions (like for objcclass)
o allow specifying an "import_dll" for external Java classes, which can
be used to specify the Java package name (like the dll for cppclass)
o take the package name into account when mangling the Java class name
o several messages that were specific to Objective-Pascal classes have
been generalised because they also apply to Java classes, same for
several compiler function names
o disabled some proccall directives for Java, but more needs to happen
(Java methods are always either instance-virtual or class-static)
git-svn-id: branches/jvmbackend@18319 -
+ added arrayreftype field to treference for the jvm, because
array loads have to be performed using special instructions,
so this information has to be passed on to the code generator.
This information will have to be added in t(cg)vecnode.
* moved concatenating the generated code for a procedure to the
al_procedures list to thlcg.record_generated_code_for_procdef(),
which is overridden by jvm/hlcgcpu to attach that code to the
procdef it belongs with. The reason is that a Java class file
can only contain code for one class, so we have to write out
the assembler grouped per class instead of in the order the
routines appear in the source code
* also committed forgotten changes in psub after moving the
register allocator initialisation to hlcgobj
git-svn-id: branches/jvmbackend@18308 -
a separate method (defaultmangledname)
* for the jvm target, call jvmmangledname() instead of defaultmangledname()
from mangledname()
* make non-strict private and protected methods "public" in the Java bytecode,
because a single Java class file contains only code from one class, and such
methods can be accessed from other classes in the same unit too
* minor fixes to the jvm mangled name generation
git-svn-id: branches/jvmbackend@18303 -
whether the mangled name is for defining a symbol, or for referencing
it later (e.g. for a call or load of its address). The reason is that
on the JVM both cases are different.
+ jvmdef unit to encode types according to the JVM rules
+ tprocdef.jvmmangledname() to encode a procdef's JVM mangled name
(the common part of defining/referencing it; tprocdef.mangledname
afterwards adorns it as required)
git-svn-id: branches/jvmbackend@18288 -
* when creating a child class, ignore the padding added to the parent
in case of objcclasses (gcc/clang also do that; maybe the same
has to be done for cppclass as well)
-> objcclass layouts seem to finally completely match the gcc ones
git-svn-id: trunk@18119 -
* save/restore tabstractrecordsymtable.datasize as asizeint instead of
aint (not ppu version change because they are the same on all
production targets)
* add shortint() typecasts when reading/writing fieldalignment/
recordalignment fields
git-svn-id: trunk@18118 -
because it influences the offset at which the next field in child classes
should be placed in case it also uses C_alignment
* also pad objectdefs based on the packrecords setting (Delphi-compatible)
-> field offset calculation in objcclasses is now correct if they are
compiled with {$packrecords c}
git-svn-id: trunk@18114 -
undefined for now as long as
systems_interrupt_table set
defined in systems unit is empty.
This removes several warnings from compiler compilation.
git-svn-id: trunk@17871 -
