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 -
