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 -
