* 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 -
* 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 -
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 -
(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 -
overflow (don't know what the y-coordinate is at that point, because the
window may be wider than the artificial screenwidth) (mantis #20880)
git-svn-id: trunk@21925 -
symtable.pas, searchsym_in_class:
* if we found a helper method that has overload defined we should not forget the symbol as there can be a case that no method with that name is defined in the extended class hierarchy
symtable.pas, searchsym_in_record:
* analogous to the above
+ added test given in the issue
+ added analogous test for record helpers
git-svn-id: trunk@21764 -
This fixes 64bit shifts on arm with a constant shift value of 0.
The old code would have emitted something like this
mov r0, r0, lsl #32
as 32 is an invalid shift value (and would be wrong anyway) the
assembler declined to assemble the produced source.
The new code will just not emit any code for a shift value of 0.
tests/test/tint642.pp now tests shl/shr 0 on 64 bit values.
tests/webtbs/tw22326.pp is also added as an additional test.
git-svn-id: trunk@21746 -
fist(t)pq instructions (mantis #22331)
* also internalerror in case the internal fpu stack position counter
becomes larger than 7, so we don't have to wait for the entire
byte to overflow before we detect a problem
git-svn-id: trunk@21734 -
* ptype.pas, read_named_type, array_dec:
allow border checks if both range elements are orddefs; for normal arrays
using e.g. "0..15" this will allow to declare the correct amount of
elements in the initialization while for generic arrays (e.g. "0..SizeOf(T)")
this will mean that only one element can be declared, which was already the
case before this change (maybe in such cases a constant initialization should
be forbidden in the future...)
+ added test
git-svn-id: trunk@21690 -
* pgenutil.pas: factor out the reading of generic specialization parameters (parse_generic_specialization_types) and the generation of a generic type name (generate_generic_name)
* pdecsub.pas, parse_proc_head:
* also allow an interface alias declaration if an identifier is followed by a "<" (which starts a specialization)
+ add a procedure "consume_generic_interface" which parses such a specialization (by using "parse_generic_specialization_types") - this is needed, because "consume_generic_type_parameter" can (and should not!) handle "ISomeIntf<Integer, T>" or (somewhen in the future) "ISomeIntf<TSomeOtherGeneric<T>>" - and finds the correct symbol for the interface (by utilizing the "generate_generic_name" function)
* generate the correct mapping entry (for the generic it's only needed for checking (if any), but for a specialization it's essential that we reference the correct specialization)
+ add tests which were included with the issue and also two additional ones
Note: In non-Delphi modes an interface alias can be done like in Delphi mode; "specialization" is not necessary and furthermore not even allowed!
git-svn-id: trunk@21656 -
* pscanner.pas: change SizeInt to ASizeInt for tokenreadsizeint and tokenwritesizeint and change necessary other locations for record- and replaytokenbuffers
+ Added a test in the hope that some test-platforms do cross platform (e.g. win32 => win64) compilation.
git-svn-id: trunk@21651 -
* pparautl.pas, insert_funcret_para:
assume that the result in a generic function/method can not be passed in a param
* pparautl.pas, insert_funcret_local:
don't call ret_in_param, but create the symbol as we need a valid funcretsym
* pstatmnt.pas, assembler_block:
don't modify the framepointer for a generic method/function
* rautils.pas, TOperand.SetupResult:
don't assume that we can't use the result for a generic function/method
git-svn-id: trunk@21608 -
+ pgenutil.pas:
add a procedure which adds a type symbol to a non-Delphi-mode generic class or record which has the same name as the unit global dummy symbol for that generic. I don't know why I had that idea earlier as this will simplify some of the conditions in the parser again (I haven't changed these yet, but I hope to do that at least when I start working on generic functions).
* pgenutil.pas, generate_specialization:
correctly handle "specialize TSomeGeneric<T>" as method parameter in a generic with the newly added rename symbol
* pdecobj.pas, object_dec & ptype.pas, record_dec:
call the procedure to add the rename symbol (the procedure checks whether the mode is correct)
* ppu.pas:
increase PPU version so that we don't use non-Delphi mode units with generics, but without the rename symbol
+ added tests:
the one in webtbs are for classes/objects and those in test are for records
git-svn-id: trunk@21603 -
* pdecsub.pas, parse_proc_dec & pdecobj.pas, constructor_head:
correctly set the return type of the constructor of a class helper to the extended def
* psub.pas, generate_bodyentry_block:
call the NEWINSTANCE of the extended class for constructors of class helpers
git-svn-id: trunk@21582 -
procdef, so that the unit containing it is marked as "used" (mantis #15966)
Even better would be if the unit containing the originally found procsym
were not also marked as used, but that would require a significant
rewrite (all symbols found using symboltable helpers are automatically
marked by those routines)
git-svn-id: trunk@21501 -
