* extend parse_proc_head() with the ability to deal with specializations of procdefs
Note: such a procdef is created as unregistered as this is used to determine the correct overload in tcallcandidates (through the use of the yet to be adapted generate_specialization_phase2())
git-svn-id: trunk@31771 -
* extend parse_proc_head() with support for /parsing/ generic functions (at least in mode Delphi, mode ObjFPC depends on the new isgeneric parameter to be set)
* adjust parsing of interface mappings with a generic interface (note: in mode ObjFPC this now requires a "specialize" directly before the generic interface's name, which is more in line with other uses of "specialize")
pexpr.pas, factor:
* don't call postfixoperators() if hadspecialize is set
tests/test/tgeneric79.pp:
* adjust test to changed syntax
git-svn-id: trunk@31769 -
* for now all objectdefs are created as registered
Note: an additional parameter instead of an overload is used for tobjectdef.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: trunk@31592 -
pdecobj.pas, object_dec:
* Always check for genericdef and genericlist and not genericdef and ifnot then genericlist.
+ added test
git-svn-id: trunk@27877 -
For partial specialization only the declaration is reparsed, but not method bodies.
The way generic parameters are passed around inside the compiler is changed: instead of creating new type symbols we keep a (name,def) pair so that the code in insert_generic_parameter_types can decide whether it needs to add a type symbol (for new undefined defs) or not (for real types and undefined defs that were passed on from the parent generic). This required the tfpobjectlist type of the genericlist variables/parameters to be changed to tfphashobjectlist.
For correctly parsing Delphi specializations as parameters in functions of records (or objects) the relationship between the def and its typesym must already be established during the parsing. For this the checks for forcing a "type is not completely defined" message needed to be adjusted to correctly handle nested types as well. This should as a sideeffect also allow the usage of nested constants, etc like was fixed for classes some months ago.
ToDo:
- if a generic is specialized with only fully defined types then we could generate the in the unit where it's used. This is not yet done.
- currently we don't specialize generics that are currently parsed; maybe this could be improved in the future for better type compatibility checks
- check whether the pausing of token recording for partial specializations works correct in context of hint modifiers
pgenutil.pas:
* parse_generic_parameters: return a tfphashobjectlist instead of a tfpobjectlist (requires a few type adjustments in various other declarations)
* maybe_insert_generic_rename_symbol, insert_generic_parameter_types: change genericlist from tfpobjectlist to tfphashobjectlist
* parse_generic_specialization_types_internal: use is_generic instead of checking for df_generic
* generate_specialization:
+ add a nested function to disable the requirement to check for method bodies
* use the "simple" parameter parsing only for error recovery
* instead of already creating a new type symbol for a parameter we use the found symbol's name and its def and maybe create it later on (therefor the type of tfpobjectlist was changed to tfphashobjectlist)
* a partial specialization is specialized into the symtable of the def it is specialized in instead of one of the two global symtables
* for now we handle partial specializations of generics we are currently parsing like before
* don't continue recording generic tokens while we do a partial specialization
* use the new unset_forwarddef function on the newly created defs
* insert_generic_parameter_types: only create a new type symbol if the found type symbol does not yet have an owner (thus was freshly created for this generic declaration)
pdecobj.pas, object_dec:
* change type of genericlist from tfpobjectlist to tfphashobjectlist
* set the type sym for all object types that can be generic or inside a generic (needed for correctly parsing Delphi style generic declarations)
pdecsub.pas, parse_proc_head:
* consume_generic_interface: always generate the specialization name as now all generics are "specialized" inside a generic
* the assumption that the def index numbers are the same is no longer true as the genericdef might contain the defs of partial specializations which are not generated for full specializations
pdecvar.pas, read_record_fields:
* we also need to check nested types whether they contain a not yet completely parsed record or object
ptype.pas:
* read_named_type:
* change genericlist from tfpobjectlist to tfphashobjectlist
* pass the typesymbol along to record_dec
* resolve_forward_types: use is_generic instead of checking for df_generic
* single_type:
* use is_generic instead of checking for df_generic
* no need to check generic parameters
* parse_record_members:
+ add parameter for the record's type symbol
* setup the typesym <=> def relationship
+ record_dec: add parameter for the type symbol and pass it to parse_record_members
* read_named_type, expr_type: use is_generic instead of checking for df_generic
* array_dec & procvar_dec: change genericlist from tfpobjectlist to tfphashobjectlist
symdef.pas, tstoreddef:
* improve the checks used in is_generic and is_specialization to really only work on true generics and true (and partial) specializations respectively
* don't search the type parameters in the symtable, but store them in the PPU and load them from there
- remove fillgenericparas method (including the calls in the descendants tarraydef, tprocvardef, tobjectdef and trecorddef)
defcmp.pas, compare_defs_ext:
* handle partial specializations: specializations with only undefineddefs are compatible to generic defs
pdecl.pas, types_dec:
* switch generictypelist from tfpobjectlist to tfphashobjectlist
ppu.pas:
* increase PPU version
+ added tests that ensure that "not completely defined" checks for records (and objects) still work correctly
git-svn-id: trunk@27861 -
nestedprocpointertype; this was done initially before the JVM target knew
about the voidpointertype, but is no longer necessary (also fixes
mantis #26251)
git-svn-id: trunk@27838 -
o made all (non-abstract) tdef and tsym constructors virtual
o added c*def/c*sym classref types for every (non-abstract) t*def/t*sym
class
o added cpusym unit for every architecture that derives a tcpu*def/tcpu*sym
class from the base classes, and initialises the c*def/c*sym classes with
them. This is done so that the llvm target will be able to derive from
the tcpu*def/sym classes without umpteen ifdefs, and it also means that
the WPO can devirtualise everything because the c* variables are only
initialised with one class type
o replaced all t*def/t*sym constructor calls with c*def/c*sym constructor
calls
git-svn-id: trunk@27361 -
+ globtype.pas: add new modeswitch to modeswitch enum and name array
* ptype.pas & pdecobj.pas: check for new modeswitch instead of modeswitch class
* ppu.pas: increase ppu version as we've added a new modeswitch which requires correctly compiled units
* adjusted tests to enabled the modeswitch when necessary
+ added three new tests that check for correct functionality of modeswitch typehelpers
git-svn-id: trunk@26796 -
defcmp.pas:
+ add new function "def_is_related" which combines the "is_related" overloads of "tobjectdef", "trecorddef" and "tstringdef" (it returns "false" for other def types which is what "tdef.is_related" did)
* compare_defs_ext & compatible_childmethod_resultdef: change call from "x.is_related" to "def_is_related(x,...)"
symtype.pas, tdef:
- remove "is_related" method
symdef.pas:
- remove "is_related" in "tobjectdef", "trecorddef" and "tstringdef"
* tobjectdef.needs_inittable: for checking whether a Corba interface somehow inherits from a IInterface don't use "is_related" anymore (we want to avoid the dependency after all), but mimic the necessary functionality of "def_is_related"
htypechk.pas, nadd.pas, ncal.pas, ncnv.pas, ngtcon.pas, nld.pas, optvirt.pas, pdecobj.pas, pdecvar.pas, pexpr.pas, pgenutil.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
symtable.pas
+ use unit defcmp
* change call from "x.is_related" to "def_is_related(x,...)"
jvm/njvmcnv.pas, jvm/njvmflw.pas:
* change call from "x.is_related" to "def_is_related(x,...)"
git-svn-id: trunk@25847 -
defcmp.pas:
+ add function "find_implemented_interface"
* change method call of "find_implemented_interface" into function call
symdef.pas:
- tobjectdef: remove method "find_implemented_interface"
- remove use of unit "defcmp"
pgenutil.pas:
* change method call of "find_implemented_interface" into function call
+ add use of unit "defcmp"
ncgcnv.pas, ncnv.pas, pdecobj.pas, pdecsub.pas, pdecvar.pas:
* change method call of "find_implemented_interface" into function call
git-svn-id: trunk@25844 -
compiler/pdecobj.pas, object_dec:
* since revision 25518 the global symtable of the current module is no longer popped and pushed again so that the defaware symtablestack can add the helper; thus we need to do this not only for static symtables, but for global ones as well
* adjusted comment to reflect current situation
git-svn-id: trunk@25834 -
interface: the compiler does not/cannot check whether the class
implements all required methods in that case, and it moreover leads to
crashes (mantis #24184). Older versions of Delphi did allow this (and
don't check whether the interface methods are implemented either), but
that's simply a (similar) bug in Delphi that has been fixed in XE at
least
* fixed compilation of webtbs/tw2727 after this fix
git-svn-id: trunk@24177 -
symconst.pas:
+ extend "thelpertype" by "ht_type" which tells the code in "pdecobj.parse_extended_type" that a type helper declaration has been parsed
node.pas:
+ add a constant which identifies all constant node types
ptype.pas:
+ read_named_type: add a parameter "hadtypetoken" to tell the code whether a "type" token had been parsed before
+ read_named_type: if an identifier "helper" is parsed we need to check whether "hadtypetoken" is true and the modeswitch "m_class" is set, but the "m_delphi" one is not; in that case we have a "type helper" declaration
pgenutil.pas, generate_specialization:
* adjust call to read_named_type
pdecl.pas, types_dec:
* adjust call to read_named_type
pdecobj.pas:
* parse_extended_type: extend for correct handling of primitive types (includes Delphi compatible handling as well) and reject types that are explicitly not allowed
* method_dec: require "static" for class methods in type helpers
* method_doc: allow constructors for type helpers as well
paramgr.pas, tparamanager:
* set_common_funcretloc_info: handle type helper constructors like record constructors
* handle_common_ret_in_param: the "self" value of a type helper constructor is also returned in a parameter
pexpr.pas:
+ add a function to postfixoperators which tries to find and apply a type helper for a given type
* postfixoperators: try to apply type helpers for ordinal constants
* postfixoperators: use the correct string type for string constants
* postfixoperators: try to apply type helpers for enum constants
* postfixoperators: try to apply type helpers for arrays
* postfixoperators: try to apply type helpers for Variant
* postfixoperators: try to apply type helpers for pointer types
* postfixoperators: try to apply type helpers for other types
* factor: check postfixoperators after _REALNUMBER, _CCHAR, _CWCHAR, _TRUE and _FALSE
* factor: also check postfixoperators if a _POINT follows a _NIL
symdef.pas, tdefawaresymtablestack.addhelpers:
* use "generate_objectpascal_helper_key" to generate the key
symtable.pas:
+ add function to generate the key value for the map of extended types using the extended def
* adjust "search_last_objectpascal_helper" and "search_objectpascal_helper" to handle primitive types as well
* use the new "generate_objectpascal_helper_key" function to generate the key
pparautl.pas:
* insert_self_and_vmt_para: don't insert the $vmt symbol for record or type helpers (ToDo: check whether class helpers really need the symbol as well)
* insert_self_and_vmt_para: pass "self" as var parameter for type helpers as well
psub.pas, generate_bodyentry_block:
* also allow type helpers for constructor methods
ncal.pas, tcallnode.gen_self_tree:
* also use a temp variable for type helper constructors
ncgcal.pas, tcgcallnode.secondcallparan:
* allow Pointers to be passed as address param if it is the Self value of a type helper extending a pointer type
* correctly handle the location in case of type helper constructors
+ add tests
git-svn-id: trunk@23580 -
order to minimise memory losses due to alignment padding. Not yet enabled
by default at any optimization level, but can be (de)activated separately
via -Oo(no)orderfields
o added separate tdef.structalignment method that returns the alignment
of a type when it appears in a record/object/class (factors out
AIX-specific double alignment in structs)
o changed the handling of the offset of a delegate interface
implemented via a field, by taking the field offset on demand
rather than at declaration time (because the ordering optimization
causes the offsets of fields to be unknown until the entire
declaration has been parsed)
git-svn-id: trunk@21947 -
+ pgenutil.pas:
add a procedure which adds a type symbol to a non-Delphi-mode generic class or record which has the same name as the unit global dummy symbol for that generic. I don't know why I had that idea earlier as this will simplify some of the conditions in the parser again (I haven't changed these yet, but I hope to do that at least when I start working on generic functions).
* pgenutil.pas, generate_specialization:
correctly handle "specialize TSomeGeneric<T>" as method parameter in a generic with the newly added rename symbol
* pdecobj.pas, object_dec & ptype.pas, record_dec:
call the procedure to add the rename symbol (the procedure checks whether the mode is correct)
* ppu.pas:
increase PPU version so that we don't use non-Delphi mode units with generics, but without the rename symbol
+ added tests:
the one in webtbs are for classes/objects and those in test are for records
git-svn-id: trunk@21603 -
* pdecsub.pas, parse_proc_dec & pdecobj.pas, constructor_head:
correctly set the return type of the constructor of a class helper to the extended def
* psub.pas, generate_bodyentry_block:
call the NEWINSTANCE of the extended class for constructors of class helpers
git-svn-id: trunk@21582 -
* symtable.pas:
+ add function "get_generic_in_hierarchy_by_name" which returns a def with the name of the symbol in the given object/record hierarchy (useful only in non-Delphi modes)
+ add function "return_specialization_of_generic" which returns the specialization def of a given class inside the given object/record hierarchy
* pexpr.pas, factor, factor_read_id: instead of checking whether the names of the found symbol and the current_structdef are equal, check whether the generic appears in hierarchy of current_structdef
* ptype.pas:
* id_type: check whether the found symbol is a generic dummy and we are currently parsing a generic then return the correct def of the generic instead of the dummy one
* single_type: when using the generic type without type parameters the def must resolve to the specialized def when specializing the class instead of the generic def which the dummy symbol points to
* read_named_type, expr_type: like in "single_type" we need to resolve the use of the parameterless type name to the correct specialization def instead of the generic def
* pdecobj.pas, object_dec: also set the typesym of the current_structdef as otherwise some assumptions about generics with the above mentioned changes aren't valid anymore (like the def the typesym is unset again afterwards)
+ add tests for both bug reports (the one for 19499 is slightly modified so that it does not contain any errors)
git-svn-id: trunk@21361 -
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 -
Always define nested types of a generic as generic as well.
* symtable.pas:
+ Add a function which decides whether two defs belong to the same generic.
* Fix sym_is_owned_by as there can be corner cases where childsym becomes Nil.
* ptype.pas:
* record_dec: Always define nested types of a generic as generic as well.
* single_type & read_named_type.expr_type:
Use the newly added function to improve the checks whether a generic
symbol should be rejected as "generics not allowed for types of
variables or fields".
+ Add a test for which the improved checks are necessary.
git-svn-id: trunk@20189 -
(= 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 -
pexpr.pas: Changes in postfixoperators and the base of handle_factor_typenode not yet incorporated (the code from trunk was simply commented for now)
git-svn-id: branches/svenbarth/generics@19676 -
The changes regarding pretty names for generics and token buffer endianess were integrated into my changes. Not every call to generate_specialization is fixed though, so compilation will fail.
git-svn-id: branches/svenbarth/generics@19674 -
This fixes the compilation of test tests\test\tgeneric29.pp and the reminder in pdecobj.pas is not needed anymore.
Note: Perhaps this behavior should be enabled in general if "parse_generic" is true (and not only if parse_parent_class if true as well).
git-svn-id: branches/svenbarth/generics@19426 -
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 -
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 -
call through to the parent method in case they are not overridden in
the child class, because otherwise the dynamic dispatch fails (looking
up a class method only checks that particular class, since they are
never virtual in Java and hence not inherited either)
git-svn-id: branches/jvmbackend@18715 -
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 -
JVM target, because that's the only way to guarantee their semantics on
that platform (see comments in pdecobj)
* allow starting new inheritance trees (which is the same as adding a new
non-virtual method as of this revision) on the JVM target in case the
parameters of the new routine match the old one, but the complete mangled
name does not (because then the JVM won't consider them to be the same
either -> Pascal semantics are matched)
git-svn-id: branches/jvmbackend@18695 -
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 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 -
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 -
