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 -
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 -
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 -
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 -
(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 -
so it can be intercepted by the JVM backend (it has to create an actual
array)
+ JVM support for the elem_2_open_array hook
git-svn-id: branches/jvmbackend@18561 -
var/out parameter (these conversions are replaced by another
construct on non-JVM targets, so didn't cause a problem there)
git-svn-id: branches/jvmbackend@18555 -
cannot insert typecasting checks on the assignment side, only on the
values that are being assigned
o since valid_for_assignment() is called in tassignmentnode.typecheckpass()
after typecheckpassing left and right, moved the conversion of the
typecheck nodes into JVM-specific constructs from typecheckpass to
pass_1, so that they can use the information whether they are on
the assignment side or not
* forbid casting a child type to a parent type on the assignment side on
managed platforms, because that circumvents the type checking
git-svn-id: branches/jvmbackend@18515 -
fpcbaserecordtype for the JVM target (intercept in ncnv via new
target_specific_general_typeconv helper, handle in as/is code)
* not only check for related types in htypechk in case they are
objdefs, but always do so (records are related to jlobject/fpcbaserecord
on the JVM target)
git-svn-id: branches/jvmbackend@18458 -
to tasnode (like for regular Object Pascal classes)
* don't collect WPO information for Java classes in tloadvmtaddrnode.pass_1()
(devirtualization can't work for Java, since classes can always be loaded
at run time, except for final/sealed classes -- but that's not yet
implemented)
+ JVM is-node support, unified JVM type checking codegen for is- and as-nodes
git-svn-id: branches/jvmbackend@18383 -
as-nodes (required for JVM target: bit pattern reinterpretations
have to be handled via conversion because of type safety reasons,
and as-nodes will also have to be able to handled class<->dynarray
checks/conversions)
git-svn-id: branches/jvmbackend@18375 -
they are constants (instead of only on 32 bit systems), and always use the
actual upper/lower bound of the loop variable instead of hardcoding the
bounds of longint (mantis #17646)
git-svn-id: trunk@16213 -
from the unit initialisation sections to the variable declaration sections
to prevent the base units from overriding derived classes (based on patch
by Hans-Peter Dietrich, mantis #17516)
git-svn-id: trunk@16118 -
that was set during the typecheck pass because typeconversion nodes
may have been optimised away previously and sometimes the resultdef is
important (e.g. for the value of callparanodes) (mantis #17458)
git-svn-id: trunk@16101 -
+ support for nested procedural variables:
o activate using {$modeswitch nestedprocvars} (compatible with all
regular syntax modes, enabled by default for MacPas mode)
o activating this mode switch changes the way the frame pointer is
passed to nested routines into the same way that Delphi uses (always
passed via the stack, and if necessary removed from the stack by
the caller) -- Todo: possibly also allow using this parameter
passing convention without enabling nested procvars, maybe even
by default in Delphi mode, see mantis #9432
o both global and nested routines can be passed to/assigned to a
nested procvar (and called via them). Note that converting global
*procvars* to nested procvars is intentionally not supported, so
that this functionality can also be implemented via compile-time
generated trampolines if necessary (e.g. for LLVM or CIL backends
as long as they don't support the aforementioned parameter passing
convention)
o a nested procvar can both be declared using a Mac/ISO Pascal style
"inline" type declaration as a parameter type, or as a stand-alone
type (in the latter case, add "is nested" at the end in analogy to
"of object" for method pointers -- note that using variables of
such a type is dangerous, because if you call them once the enclosing
stack frame no longer exists on the stack, the results are
undefined; this is however allowed for Metaware Pascal compatibility)
git-svn-id: trunk@15694 -
returns true for variants and those aren't refcounted
* also allow tempnodes for pointers to managed types to be put in
registers (not sure why it was disabled, and there are no
testsuite regressions by enabling it)
git-svn-id: trunk@15319 -
passing any value to that parameter which has the same size as the
parameter (it basically acts as if there is an explicit type conversion
to the parameter type around the value at the caller side). If a procvar
has an univ parameter, all procvars whose corresponding parameter
has the same size as that univ parameter are similarly compatible.
This transparent compatibility can however cause crashes in case of
of the procvars when one of the types is passed on the stack and the
other isn't (because then the called routine will a) load the parameter
from a wrong location and b) pop the wrong amount off of the stack at
then end). Therefore FPC will warn in most cases where this can happen.
(mantis #15777)
git-svn-id: trunk@15010 -
compares by avoiding unnecessary sign extensions (fixes bug reported in
http://lists.freepascal.org/lists/fpc-pascal/2010-January/023907.html )
* never throw away int2int type conversions on bitpacked loads, because
in these cases the proper bits still need to be selected
git-svn-id: trunk@14892 -
