pgenutil.pas, generate_specialization:
* use "is_generic" instead of "df_generic in defoptions" as nested non generic types will have that flag set as well and thus would be acceptable for the "<...>" notation although no generic version of it exists
ptype.pas, single_type:
* check for nested types after doing a specialization
+ added tests (one for now working case and one for now forbidden case)
git-svn-id: trunk@25578 -
cclasses.pas:
+ TFPHashList & TFPHashObjectList: add WhileEachCall methods that walk the list like ForEachCall does, but uses a while-loop instead of a for-loop
psub.pas, generate_specialization_procs:
* use WhileEachCall instead of ForEachCall as new defs can be added during the specialization that need to be specialized as well
+ added test
git-svn-id: trunk@25577 -
now that there is no special assigned handling anymore, because the
generic "<>nil" code for method pointers loads the "proc" field
via an internally generated tmethod() typecast (using the
methodpointer type). Additionally, not loading this type was
an artefact from the time that it wasn't available yet for the
JVM target
git-svn-id: trunk@25558 -
(we previously internally generated assigned(unicode/ansistring) nodes,
which now cause typecheck errors because there is no special assigned
handling anymore)
git-svn-id: trunk@25557 -
+ added extra check to ensure that {$apptype console} and {$apptype gui} produce a warning and do not change the binary format to .exe on msdos
git-svn-id: trunk@25547 -
symtable.pas:
+ add new tsymbol_search_flag type which can be passed to various searchsym* routines
+ add support to not call "addsymref"
+ add new searchsym_with_flags function that calls searchsym_maybe_with_symoption
* adjust searchsym_maybe_with_symoption, searchsym_in_class & searchsym_in_helper to use new flag type instead of Boolean arguments
* adjust searchsym & searchsym_with_symoption which call the modified functions
nutils.pas, handle_staticfield_access:
* adjust searchsym_in_class call
pexpr.pas, handle_factor_typenode, postfixoperators, factor:
* adjust searchsym_in_helper and searchsym_in_class calls
pinline.pas, new_function:
* adjust searchsym_in_class call
scanner.pas, try_consume_nestedsym:
* adjust searchsym_in_class call
fmodule.pas, tmodule:
+ add genericdummysyms field which is a TFPHashObjectList that contains TFPObjectList instances per generic dummy that in turn contains tgenericdummysyms instances
pgenutil.pas:
+ add function split_generic_name to split a generic name into non-generic name and count value of type parameters
+ add function resolve_generic_dummysym which tries to use the new genericdummysyms field to find the real symbol of a dummy sym
* generate_specialization: adjust searchsym_in_class call
* specialization_init/specialization_done: save/restore genericdummysyms of module
symdef.pas, tdefawaresymtablestack:
+ add new intermediate method pushcommon which is used by both push and pushafter
+ add new intermediate method remove_helpers_and_generics (which calls remove_generics and remove_helpers if necessary)
* rename removehelpers to remove_helpers
* rename addhelpers to add_helpers_and_generics and extend it to correctly fill current_module.genericdummysyms
* call remove_helpers_and_generics from pop instead of remove_helpers
ptype.pas, single_type, read_named_type.expr_type, read_named_type:
* try to resolve symbols with sp_generic_dummy with resolve_generic_dummysym
+ added test
git-svn-id: trunk@25519 -
1. It allows to use comparative operators in some unusual cases (issue #25004).
2. Regular type checking does not allow to use other than Boolean types in IF expressions anyway.
3. Delphi compatibility (although Delphi documentation states otherwise).
git-svn-id: trunk@25494 -
- move operator_levels to topens.pas - it is used from 2 units now
- implement pexpr like sub_expr for preprocessor expressions
- implement +,-,*,/ expressions for the moment
* move OR, AND, IN implemenetation to the new logic
git-svn-id: trunk@25465 -
* support TRUE,FALSE for all modes
* refactor texprvalue.evaluate to support arithmetic expressions and implement them here
* simplify read_expr and read_factor code
git-svn-id: trunk@25463 -
Therefor the cpu type (-Cp...) "coldfire" was split up into "isaa", "isaa+", "isab" and "isac". The Linux RTL can currently compiled for "68020", "isab" and "isac". For the other three Bcc.L must be handled differently (only Bcc.B/W supported) and for "68000" also EXT.L needs to be handled differently.
fpcdefs.inc:
+ define CPUCAPABILITIES if capabilities can be set for a certain CPU type (currently ARM, AVR and M68k)
options.pas:
* check for CPUCAPABILITIES instead of specific CPUs
assemble.pas:
- the handling of the CPU type is already done in m68k/ag68kgas.pas, Tm68kGNUAssembler.MakeCmdLine (and thereby already using the gascputypestr array!)
m68k/cpuinfo.pas:
- tcputype: remove "cpu_coldfire"
+ tcputype: add "cpu_isa_a", "cpu_isa_a_p", "cpu_isa_b" and "cpu_isa_c"
+ add "cpu_coldfire" constant which contains all Coldfire specific cpu types
* adjust "cputypestr" and "gascputypestr"
+ add tcpuflags and cpu_capabilities (DBRA restriction was checked with CPUCOLDFIRE, CAS/TAS will be needed for atomic operations and BRAL restriction was discovered during testing of new cpu types)
m68k/cgcpu.pas:
* adjust checks for "cpu_coldfire"
m68k/n68kadd.pas:
* don't use a BRA.L if it is not supported, but (at least for now) a BRA.W
aggas.pas:
* adjusted check for Coldfire
git-svn-id: trunk@25457 -
