The main adjustments were as follows:
- fixing coding style and identation
- fixing some typos
- using a better name for the property in tcallcandidates which holds the symbols created for anonymous parameter values
overrides but before generating the VMT, so that these hidden parameters
are part of the procdefs stored in the VMT (fixes some LLVM type errors
after r41716)
git-svn-id: trunk@41884 -
so that they take into account inherited calling conventions (mantis #35233)
o don't needlessly calculate the paraloc info when generating a JVM mangled
name
git-svn-id: trunk@41716 -
on pdecsub (node units should not depend on parser units):
o maybe_add_public_default_java_constructor()
o handle_calling_convention()
o create_finalizer_procdef() (replaced with create_outline_procdef())
o insert_record_hidden_paras()
o handle_calling_convention()
o proc_add_definition()
o build_parentfpstruct()
o maybe_guarantee_record_typesym()
o get_first_proc_str()
* factored out the creation of a procinfo for a nested procdef based on a
subnodetree of the current procdef into tprocinfo.create_for_outlining()
git-svn-id: trunk@40773 -
This fixes Mantis #31634 as far as I see it useful to; anything further would probably require extension of the message generation system by a context or such so that the compiler could write "Error in TFoo<Integer>: ..." instead of merely "Error: ..." or something like that.
No test added due to the nature of the bug.
git-svn-id: trunk@35748 -
+ added test
Note: the test is added to webtbs although it's right now still failing, cause I'll remove the restriction for nested procedures since the compiler now supports them correctly. Due to the way we handle generics we don't have problems with them unlike Delphi.
git-svn-id: trunk@35147 -
these are generated after the other specialisation methods (via
add_synthetic_method_implementations, rather than via
generate_specialization_procs)
o fixes crash in tests/test/jvm/tw20212.pp
git-svn-id: trunk@34036 -
pgenutil.pas:
* process_abstractrecorddef & generate_specialization_procs: also check for a forward def is the other module is still compiling (thus an access to tprocdef.forwarddef should still be possible); this might happen due to circular references like in tests/test/tgeneric91.pp
git-svn-id: trunk@33872 -
pgenutil.pas:
+ new function maybe_add_pending_specialization() to add a pending specialization if it belongs to the current unit
* generate_specialization_phase2: don't set up the owner as this leads to problems when using overloaded generic routines and don't add it to the pending list if it's a procdef
ncal.pas, tcallnode:
* pass_typecheck: if we have a specialization then add it to the pending specializations once we know that we use it
git-svn-id: trunk@33843 -
pgenutil.pas:
* process_procdef & process_abstractrecorddef: only check whether the procdef's generic is still a forward declaration if it's in the current unit (otherwise we would trigger an internal error)
git-svn-id: trunk@33828 -
fmodule.pas, tmodule:
+ new list pendingspecializations which keeps track of all pending specializations of the current module
psub.pas:
* move generate_specialization_procs and related routines to pgenutil
+ new procedure read_proc_body to read a routine's body, cause generate_specialization_procs needs it (unlike the already existing overload in the implementation section, this one can only handle bodies of non-nested routines)
pgenutil.pas:
* generate_specialization_phase2: add the newly specialized generic to the current module's pending specializations
* generate_specialization_procs: reworked so that it uses the new pendingspecializations field instead of walking the global and local symboltable of the current unit
pmodules.pas:
+ add pgenutil to uses due to the moved generate_specialization_procs
+ added test
git-svn-id: trunk@33826 -
scanner.pas, tscannerfile:
+ new method is_recording_tokens to check whether token recording is already active
pdecsub.pas, parse_proc_directives:
* record tokens into the declaration token buffer of a generic routine if necessary
pgenutil.pas, generate_specialization_phase2:
* process the procedure directives that had been recorded with the generic routine
git-svn-id: trunk@33824 -
pgenutil.pas:
* parse_generic_specialization_types_internal: ignore the parasymtable of procvars (as before the addition of generic routines) and instead use the type's hierarchy name
* generate_specialization_phase2: specialize types of procvars into the parameter symtable as they don't have a local one
+ added test
git-svn-id: trunk@33544 -
psub.pas, tcgprocinfo.parse_body:
* ensure that parse_generic and current_genericdef are set correctly when parsing a generic routine
pgenutil.pas, generate_specialization_phase2:
* when we're specializing inside a generic we don't want to have the routine definitions, so let the compiler assume that the routine is no longer a forward definition
+ added test
git-svn-id: trunk@33275 -
pexpr.pas:
+ new enum texprflag and corresponding set texprflags
* comp_expr: replace accept_equal and typeonly with texprflags parameter
* factor: replace typeonly and hadspecialize with texprflags parameter
* sub_expr: replace accept_equal and typeonly with texprflags parameter
* adjust calls to comp_expr(), factor() and sub_expr()
other units:
* adjust calls to comp_expr(), factor() and sub_expr()
git-svn-id: trunk@32269 -
the defs and syms (recursively) referred by inline routines and by the WPO
info
o defs and syms are no longer added immediately to the module's deflist/
symlist, even if they are created as "registered". Instead,
"doregister=true" simply means "add it to the symbol table at the
top of the symtable stack"
o normally only when a sym/def is deref'ed, it gets added to the module
symlist/deflist and defid/symid gets a (unique) value
o in cases where we use(d) the defid to construct unique names within the
current module, you now have to call call the tdef.new unique_id_str()
method. If the def was not yet registered, we will reserve room for it
in the deflist (to get a unique id), but the defid gets set to a
negative value computed from its position in the deflist. Should it
have to be written to the ppu file later on, the defid will be
modified to the actual position in the deflist. For both values,
new unique_id_str() will return the same result so that references
to this def before and after actual registrations are the same (needed
for the JVM backend, but also a good principle in general)
Overall: don't directly use symid/defid anymore to get unique identifiers,
but use tdef.new unique_id_str() instead (if necessary, a similar routine
for tsym can be added)
The result is the ppu file size gets reduced significantly after its big
increase as a result of the high level typed constant builder (which creates
a lot of defs). The result is even more efficient than before, as other
unneeded defs/syms from the localsymtables don't get saved/restored anymore
either.
git-svn-id: trunk@32153 -
+ export parse_proc_dec_finish() from the unit
pgenutil.pas:
* adjust generate_specialization_phase2() to correctly specialize procdefs
git-svn-id: trunk@31772 -
* no longer create the type symbol and the defs as registered
pdecl.pas, types_dec:
* register the syms and defs of the parsed generic parameters
git-svn-id: trunk@31758 -
* for now all undefineddefs are created as registered
Note: an additional parameter instead of an overload is used for tundefineddef.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: trunk@31757 -
* in case of an inline specialization inside a generic function's/method's parameter list using type parameters of the generic function/method itself fulltypename of the generic type parameter must not be used as the procdef is not yet owned by anyone; this is no problem for non-generic functions/methods or specializations with type parameters that don't belong to the generic function/method, because they don't have the generic, ownerless procdef as owner => use a name that provides sufficient uniqueness
git-svn-id: trunk@31601 -
* 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 -
* for now all typesyms are created as registered
Note: an additional parameter instead of an overload is used for ttypesym.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: trunk@31591 -
* split generate_specialization() into two phases: generate_specialization_phase1() and generate_specialization_phase2(); the former parses the generic parameters and determines the correct generic def while the latter does the real specialization. This is needed for generic functions/methods as no full specialization needs to be done until overload selection by tcallcandidates
pgentype.pas:
+ new type tspecializationcontext
git-svn-id: trunk@31514 -
pgenutil.pas:
* parse_generic_parameters: create explicit undefineddefs for type parameters that don't have a constraint
* insert_generic_parameter_types: move the created undefineddefs from the parent symtable to the generic's symtable
defcmp.pas, compare_defs_ext:
* in case the flag for strict undefineddef checks is set don't consider two different undefineddefs as compatible
+ added tests
git-svn-id: trunk@30705 -
(abstract)recordsymtables, so that these settings don't depend on the
current user settings when internally creating record definitions
git-svn-id: branches/hlcgllvm@30343 -
pgenutils.pas:
+ generate_generic_name: new parameter owner_hierarchy to further influence the specialization name
* generate_specialization: pass the ownerhierarchy name to generate_generic_name
pdecsub.pas, parse_proc_head:
* parse_generic_interface: for now pass '' to the hierarchy parameter; it needs to be checked whether Delphi allows nested interfaces there as well
git-svn-id: trunk@29769 -
pgenutil.pas:
* parse_generic_parameters: a ';' terminates a parameter group, so correctly adjust firstidx in that case
+ added test
git-svn-id: trunk@29685 -
pgenutil.pas:
* parse_generic_parameters & insert_generic_parameter_types: create the type parameter symbols as strict private instead of public (which is the default visiblity)
* adjusted two tests which relied on this behavior (that's why I fixed the type aliases previously)
+ added test
git-svn-id: trunk@29486 -
pgenutil.pas, specialization_init:
* don't push the localsymtable if the unit does not have one available
+ added test (needs manual execution though... :/ )
git-svn-id: trunk@29172 -
pgenutil.pas, generate_specialization:
* first check whether we can reuse the current specialization or another specialization and only /then/ retrieve the symtable to specialize to
+ added test
git-svn-id: trunk@28705 -
pgenutils.pas, check_generic_constraints:
* correctly handle forward defs if the constraint is either a single IInterface/IUnknown or a TObject/class
+ added tests
git-svn-id: trunk@28601 -
pgenutil.pas, generate_specialization:
* also search for the generic type in general if it was previously found in a record/class as there might be a non-generic type (or one with a different number of parameters) defined elsewhere
+ added test
git-svn-id: trunk@28244 -
ptype.pas:
* read_named_type: change hadtypetoken from a value to a var parameter and set it to false if a type helper is parsed so that calling code does not handle it as unique
* read_anon_type: handle that hadtypetoken is now a var parameter
pgenutil.pas, generate_specialization:
* handle that hadtypetoken of read_named_type is now a var parameter
+ added test
git-svn-id: trunk@27870 -
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 -
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 -
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 -
pgenutil.pas, generate_specializations:
* use splite_generic_name
* use the genericparas list instead of iterating the complete symlist
pgenutil.pas, split_generic_name:
* leave the loop instead of providing an internal error if the right part is not a number
git-svn-id: trunk@25580 -
pgenutil.pas:
+ add new function could_be_generic which checks whether a given symbol name could be a generic (which is determined using the genericdummysyms list for the current module)
pexpr.pas:
* factor: only do a typecheck pass (postfixoperators does one as well) if the found node can not be a generic type
* sub_expr: do a typecheck pass if it isn't a specialization
+ added test
git-svn-id: trunk@25579 -
pgenutil.pas, generate_specialization:
* use "is_generic" instead of "df_generic in defoptions" as nested non generic types will have that flag set as well and thus would be acceptable for the "<...>" notation although no generic version of it exists
ptype.pas, single_type:
* check for nested types after doing a specialization
+ added tests (one for now working case and one for now forbidden case)
git-svn-id: trunk@25578 -
symtable.pas:
+ add new tsymbol_search_flag type which can be passed to various searchsym* routines
+ add support to not call "addsymref"
+ add new searchsym_with_flags function that calls searchsym_maybe_with_symoption
* adjust searchsym_maybe_with_symoption, searchsym_in_class & searchsym_in_helper to use new flag type instead of Boolean arguments
* adjust searchsym & searchsym_with_symoption which call the modified functions
nutils.pas, handle_staticfield_access:
* adjust searchsym_in_class call
pexpr.pas, handle_factor_typenode, postfixoperators, factor:
* adjust searchsym_in_helper and searchsym_in_class calls
pinline.pas, new_function:
* adjust searchsym_in_class call
scanner.pas, try_consume_nestedsym:
* adjust searchsym_in_class call
fmodule.pas, tmodule:
+ add genericdummysyms field which is a TFPHashObjectList that contains TFPObjectList instances per generic dummy that in turn contains tgenericdummysyms instances
pgenutil.pas:
+ add function split_generic_name to split a generic name into non-generic name and count value of type parameters
+ add function resolve_generic_dummysym which tries to use the new genericdummysyms field to find the real symbol of a dummy sym
* generate_specialization: adjust searchsym_in_class call
* specialization_init/specialization_done: save/restore genericdummysyms of module
symdef.pas, tdefawaresymtablestack:
+ add new intermediate method pushcommon which is used by both push and pushafter
+ add new intermediate method remove_helpers_and_generics (which calls remove_generics and remove_helpers if necessary)
* rename removehelpers to remove_helpers
* rename addhelpers to add_helpers_and_generics and extend it to correctly fill current_module.genericdummysyms
* call remove_helpers_and_generics from pop instead of remove_helpers
ptype.pas, single_type, read_named_type.expr_type, read_named_type:
* try to resolve symbols with sp_generic_dummy with resolve_generic_dummysym
+ added test
git-svn-id: trunk@25519 -
pgenutil.pas, parse_generic_parameters:
* set the typesym of the newly created def so that inline specializations in pexpr.pas, sub_expr can check it correctly
git-svn-id: trunk@25410 -
symtype.pas, tdef:
+ add method "fullownerhierarchyname" which allows to retrieve the owner hierarchy name including procedure/function/method names
+ add method "fulltypename" which uses "fullownerhierarchyname" to return a full type name
symdef.pas, tstoreddef:
* implement "fullownerhierarchyname" (including caching of the result)
pgenutil.pas, parse_generic_specialization_types_internal:
* use "tdef.fulltypename" instead of "tdef.typename" to have unique values for each parsed type and thus for the specialization itself
+ tests
git-svn-id: trunk@25175 -
symsym.pas:
- remove "tgenericconstraintdata" and any using/loading/writing of it in "ttypesym"
- remove "tgenericconstraintflag"
symdef.pas:
+ add "tgenericconstraintdata"
+ load and write "genconstraintdata" in "tstoreddef"
symconst.pas:
+ add "tgenericconstraintflag" so it can be used in "ppudump" as well
defcmp.pas, compare_defs_ext:
* as we allow global operator overloads we can't really determine whether two defs are compatible, because a valid operator for the specialization types might just happen to be in scope of the generic; so for now constraints are only strictly checked when declaring a specialization
pgenutil.pas:
* adjust "parse_generic_parameters" and "check_generic_constraints" to the new location of the constraint data
ppudump.pp:
* corrrectly parse defs which contain generic constraints
git-svn-id: trunk@24628 -
