* pgenutil.pas, generate_specialization:
* return a generrordef instead of Nil when returning because of an error
* always check "genname" for a generic count string as a mode ObjFPC generic specialized in a mode Delphi unit will already contain a "$X" suffix and only symname will be set.
+ add (corrected) test
git-svn-id: trunk@22462 -
type that contains managed types, but this child doesn't contain any
managed type itself (since r16632, the parent should be considered as a
field of the child in terms of needing initialization/finalization)
git-svn-id: trunk@22461 -
* defcmp.pas, compare_defs_ext:
use the new genericparas list to check whether two specializations of the same generic can be considered equal
+ added test
git-svn-id: trunk@22454 -
The cause of the internal error was the following:
We have a generic in an unit ("A") which uses another unit ("B") in the implementation section and this other unit uses unit A in the interface section. Now the generic is specialized in the interface section of B. This leads to the problem that in unit A when it tries to load the globalsymtable of unit B that globalsymtable will be Nil, because parsing of the interface section is not yet finished. Thus the change in pgenutil.pas, specialization_init: if the unit is still "in_interface" the localsymtable needs to be used instead of the globalsymtable.
This doesn't necessarily lead to a compiling test though, as there is the following possibility:
Unit A contains a generic class/record (with methods) and uses unit B in the implementation section. This unit B also contains a generic class/record (with methods) and uses unit A in the implementation section. Both units contain a specialization of the other unit's generic outside of it's own generics (such that generate_specialization is fully triggered). Let's assume compilation starts with unit A and we reach the uses of unit B. Now compilation switches to unit B and completes as unit A is already registered and in compilation. The problem now is that the generic in unit A still contains unresolved forward declarations as the implementation section of A was not yet parsed which will lead to "forward declaration not solved" errors (Note: Delphi compiles this).
The solution to this is the following: if a generic is specialized from another unit which is not in state ms_compiled then the unit of the specialization needs to wait for the unit of the generic. So the specialization's unit adds itself into a list of waiting units of the generic's unit. Now inside "proc_unit" we need to check whether this module is waiting for other modules and if so avoid "finishing" the unit (which means generating the methods of the specialization, generating assembler code and ultimately freeing the scanner and PPU). Now when the generic's unit finishes we need to check whether other modules are waiting for it and finish them (of course it's a bit more complicated in reality, but that pretty much sums it up).
+ globstat.pas: Added an unit which handles the saving and restoring of the global state which was originally inside "parser.pas, compile" so that Don't Repeat Yourself (DRY) is respected.
* fmodule.pas, tmodule:
+ add fields to keep track of the units the module is waiting for and which modules are waiting for the module
+ add field for the saved global state (raw pointer to avoid circles)
+ add field for the state which is needed to finish the unit (raw pointer to avoid circles)
+ move the code which was used in "parser.pas, compile" after a module was successfully compiled to the new virtual method "end_of_parsing"
+ fppu.pas, tppumodule.end_of_parsing:
free the ppufile here
* pgenutil.pas:
+ add new procedure "maybe_add_waiting_unit" which adds the specialization's unit to the waiting list of the generic if that unit is not yet compiled
* generate_specialization: call the new function when we add a new (true) specialization
* specialization_init: instead of not adding implementation units at all check whether the unit is still parsing the interface section and add the localsymtable in that case
* pmodules.pas:
* change "proc_unit" to a function which returns "true" if the unit was already finished (no need to wait for other units)
+ move the code from "proc_unit" from "generate_specialization_procs" on to a new procedure "finish_unit" which
* this procedure is either called immediately in "proc_unit" if the unit does not need to wait for other units or from "finish_unit" itself if a unit that is waiting for the given unit does no longer wait for another module (special care is taken in proc_unit to avoid circles)
* parser.pas, compile:
* correctly handle the case if an unit is not finished
* use the new global state functionality from globstat.pas
* pay special attention when calling "set_current_module" (see comment at that call)
+ add tests from 22160
+ add test for above mentioned "diamond" case
git-svn-id: trunk@22452 -
hidden parameters while parsing the interface, because they may depend on
the padded size (since the size was not yet padded in the interface and
padded in the implementation, this could result in differences)
git-svn-id: trunk@22414 -
* only check whether the message identifier of an Objective-C method
matches the one from a method with the same name in a parent class
if the parameters match (todo: should be refined to "if the
encoded Objective-C selector names match")
git-svn-id: trunk@22373 -
relative to the normal stack alignment of the target (e.g., when using
ebp as framepointer, all addresses are offset 8 to the stack pointer) in
the temp generator. This enables allocating temps/locals with the correct
alignment as long as the required alignment is not bigger than the
guaranteed stack pointer alignment (fixes mantis #15582 on systems where
the stack pointer is at least aligned to 16 bytes; e.g., not yet on
i386-platforms other than darwin)
git-svn-id: trunk@22277 -
they don't have explicit side-effects, and if -Oodeadvalues (part of -O4)
is active (because it can result in the removal of range check errors,
segmentation faults, etc)
git-svn-id: trunk@22254 -
(mantis #22665)
+ support "[var wrt ..gotpcrel]" nasm/yasm syntax in intel assembler mode
for GOT-relative accesses on x86-64, + give an error when trying to do
this on win64 (it doesn't have a GOT)
* moved code that give a warning when using GOT-relative accesses to
static data on x86-64 from the AT&T reader to rax86 so it's also
active for the Intel assembler reader
+ added warning when not using GOT-relative accesses (but plain
RIP-relative instead) to global data on non-Win64 x86-64
git-svn-id: trunk@22243 -
the result location is a simple location (a single register/reference)
(mantis #22490)
* print an error when accessing "result" in a nostack pure assembler routine
if the result location is not simple
git-svn-id: trunk@22166 -
default value (mantis #22343)
* give an error when specifying an invalid default value (e.g. a
floating point number for a longint parameter)
git-svn-id: trunk@22021 -
* check "A op B" and "B op A" again for operators that can be commutative (all binary ones except shl, shr, div, mod, **, / and -)
* also check for Nil for classrefdefs if left side is a pointer (allows "TClass var" <>/= Nil again, after the above changes)
* don't allow overloads for "implicit pointer type <>/= pointer" and the other way around (this fixes non compiling Objective Pascal test tobjc21.pp and also the new toperator87.pp test)
* some formating corrections
+ added test for "TObject <> Pointer"
+ added test for "TClass <>/= Nil"
git-svn-id: trunk@21983 -
The changes are built up in a way that all operators on two given types are not allowed if a default implementation for that operator exists. This implies that there is a possibility to have a overload work for (in this order) type A and B, but not for B and A. This is for example the case for Set + Enum (which seems to have a default implementation) where Enum + Set is allowed. The added tests try to detect as many default implementations as feasible, but can't cover everything...
git-svn-id: trunk@21975 -
