Since overloading compilerprocs does not work each procedure got its own unique name, but they are using the new compilerproc extension to map them to the Insert and Delete symbol so that error messages can be shown with the respective name for the procedure declarations instead of fpc_shortstr_delete for example.
git-svn-id: trunk@33895 -
compiler/utils/pputils/ppudump.pp, readsymbols:
* ibstartsyms only contains one longint, namely the count of the symbols, not two
git-svn-id: trunk@33887 -
* g_call_system_proc: if we directly call a symbol of the system unit from another unit then it must be considered as imported as well
git-svn-id: trunk@33886 -
ninl.pas, tinlinenode:
* pass_typecheck: let code pass on to simplify() for undefineddefs in Low() and High()
* simplify: create a constant 0 as fallback
+ added test
git-svn-id: trunk@33884 -
pexpr.pas:
* handle_factor_typenode: rework code for records and objects so that Delphi style specializations are handled as well
* sub_expr.generate_inline_specialization: also do a typecheck pass on pload to be sure that we have a resultdef
+ added tests
git-svn-id: trunk@33876 -
pexpr.pas, sub_expr.generate_inline_specialization:
* do_member_read() needs to happen independently of whether we're calling a method of the same object (was incorrectly copypasted code... :/ )
+ added test
git-svn-id: trunk@33875 -
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 -
psub.pas, read_proc_body:
* also try to generate pending specializations before generating a routine's code so that these might be inlined as well
git-svn-id: trunk@33827 -
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 -
