makes them uncallable from actual Java code (javac hides them), which
is not the idea (otherwise you can't e.g. create record types in Java)
git-svn-id: branches/jvmbackend@18459 -
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 -
use of the register (can happen if the register is unused afterwards;
remove the alloc/dealloc results in no temp being allocated for the
register, so that instruction becomes invalid)
git-svn-id: branches/jvmbackend@18455 -
happens automatically when required (for constructing arrays/records;
reference counted types don't need special treatment since everything
is garbage collected)
git-svn-id: branches/jvmbackend@18453 -
hlcgobj so it can be overridden with target-specific code (e.g.,
the JVM target has to add initialisation code to allocate regular
arrays and records in constructors and unit/program initialisation)
git-svn-id: branches/jvmbackend@18452 -
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 -
(and override for the JVM, making the register type for records
R_ADDRESSREGISTER instead of R_INTREGISTER there)
git-svn-id: branches/jvmbackend@18448 -
of a forward definition don't match, since forward definitions can't
have an external name (nor can they be used in a situation where it's
necessary)
git-svn-id: branches/jvmbackend@18445 -
with temporary one when saving, since it's also freed when restoring ->
called replace_scanner() instead of save_scanner() now)
* when using -vd, print out the text that is internally generated for
injecting into the scanner
git-svn-id: branches/jvmbackend@18442 -
parameter in case of array parameters (and in case of constructors,
make the open array as "const"; heuristic, not guaranteed 100% safe!)
+ support for generating include files rather than full units (e.g., for
the system unit types), -i option
* don't generate imports for anonymous inner types ($1 etc)
* mark routines with 'package' visibility as 'public', because some packages
are split over multiple units (system unit and jdk import unit) -> allows
using these routines in illegal ways, which will result in run time errors
+ support to also select individual classes with the -x/-a parameters
+ add "virtual" modifier to methods where appropriate (so the compiler won't
force it automatically anymore)
git-svn-id: branches/jvmbackend@18439 -
for the current unit and all types/routines declared in it. The
unit itself becomes a member of this namespace as well, so in
case it's called unit1, it will be x.y.z.unit1, and type tclass
declared in it will be x.y.z.tclass. Only used for the JVM
target currently
git-svn-id: branches/jvmbackend@18436 -
(it's used for the implementation section, corrects the visibility
of functions in the implementation of Pascal units for the JVM target)
git-svn-id: branches/jvmbackend@18433 -
constructor is declared, rather than all constructors from the parent
class (because it cannot be done via scanner-injection, since some
parameter types of the parent constructors may not be visible in the
current unit, and there is no full-blown tprocdef.getcopy yet nor
a way to replace the type of the self-parameter afterwards)
* added sanity checks when inserting the parameterless constructor
(check for other identifiers called "create", and other parameterless
methods)
git-svn-id: branches/jvmbackend@18432 -
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 -
based on the parameters, but ignoring the result type. Used to
find out whether a function/procedures with these parameters
can still be added in terms of overloading (since overloading
ignores different result types, it only depends on the parameters)
git-svn-id: branches/jvmbackend@18430 -
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 -
Java classes in case it is not declared in the specified Java class,
because that will create an instance of such a parent class (in the
future, we can may automatically clone inherited constructors)
git-svn-id: branches/jvmbackend@18425 -
svn r17068,17071,17081,17136
* changed all init_paras code in both thlcgobj and ncgutil to use
location_get_data_ref() instead of direct a_load_loc_reg()/
ref.base:=reg so it also works with the JVM target
* changed all init_paras code so it works with targets that do
not pass an implicit high parameter for open array (and a similar
fix in ncgcal)
+ added support for initializing array (both regular and open)
"out" parameters of reference counted types on the JVM target
(the arrays will be initialised with nil rather than an empty
array for implementation reasons, see comments in compproc.inc)
* factored out calling of functions in the system unit directly
from hlcgobj
git-svn-id: branches/jvmbackend@18421 -
of functions at the caller side, since these will already be allocated
at the callee side
* added comment to cpupara explaining why we never allocate the function
result on the caller side and then pass it as an invisible parameter,
but instead always let the callee allocate it
git-svn-id: branches/jvmbackend@18420 -
disabled it under all circumstances on platforms that use garbage
collection for managed types since it's not required there
git-svn-id: branches/jvmbackend@18418 -
is unicodestring (does *not* change the type of "char" to "unicodechar"
(yet)). Not yet (un)selectable via a directive.
+ systems_default_unicodestring set containing systems on which the
default string type is unicodestring
git-svn-id: branches/jvmbackend@18415 -
in case -sr is used (-sr code cannot be compiled, and is only used for
debugging; with -alr, the stack slot information is printed in the
assembler file)
git-svn-id: branches/jvmbackend@18410 -
* switched to mode delphi to avoid problems with nested types in child
classes having the same name as nested types in the parent
* generate skeleton classes for all internal classes that have "package"
visibility so you can inherit from them (full definitions are not
possible because that causes circular dependencies)
-> the entire official JDK 1.5 interface, except for java.awt.Dialog
(circular dependency with java.awt.Window) can now be generated using
-a java.awt.Dialog -a sun. -a com.sun. -a apple. -protected java. javax. org.
(on Mac OS X; the "-a apple." probably has to be changed into something
else on other platforms)
git-svn-id: branches/jvmbackend@18409 -
