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 -
Note: the Sender parameter of WakeMainThread will be Nil for such threads. This is Delphi compatible.
rtl/objpas/classes/classesh.inc, TThread:
+ TThreadQueueEntry: new field ThreadID so that entries with Thread = Nil can be removed
rtl/objpas/classes/classes.inc, TThread:
* InitSynchronizeEvent: setup ThreadID field
* Synchronize: use a local TThreadQueueEntry if no TThread instance was passed in
* Queue: setup ThreadID
* RemoveQueueEvents: also check for ThreadID when trying to find the current thread
git-svn-id: trunk@33863 -
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 -
