Implemented attributes for class types and properties (based on work by Joost van der Sluis). Added TCustomAttribute - a base class for attributes. Added TUnitInfo record to RTTI. It contains the unit name and unit options (for now only a flag which specifies if the unit contains attributes). Added several tests for attributes.
git-svn-id: trunk@42356 -
so that they take into account inherited calling conventions (mantis #35233)
o don't needlessly calculate the paraloc info when generating a JVM mangled
name
git-svn-id: trunk@41716 -
on pdecsub (node units should not depend on parser units):
o maybe_add_public_default_java_constructor()
o handle_calling_convention()
o create_finalizer_procdef() (replaced with create_outline_procdef())
o insert_record_hidden_paras()
o handle_calling_convention()
o proc_add_definition()
o build_parentfpstruct()
o maybe_guarantee_record_typesym()
o get_first_proc_str()
* factored out the creation of a procinfo for a nested procdef based on a
subnodetree of the current procdef into tprocinfo.create_for_outlining()
git-svn-id: trunk@40773 -
Supporting such a prefix of course means that all section handling code ("var", "type", etc.) needs to respect the case of a "generic" token followed by "function", "procedure" or "class" and thus abort doing its own business.
Maybe I'll find the time somewhen in the future to rework the parser (plus scanner?) a bit so that code like this gets more easy to add and more importantly less ugly.
pdecsub.pas:
* extend parse_proc_dec() and parse_record_method_dec() so that they can be told that they are supposed to handle the to be parsed function/procedure/method header as a generic
pdecvar.pas:
+ new entry for tvar_dec_option named "vd_check_generic" to tell read_var_decls() and read_record_fields() to look out for "generic"
* extend read_var_decls() and read_record_fields() to check for "generic" if needed and to clean up correctly if it is encountered
pdecl.pas:
* the section handling procedures types_dec(), resourcestring_dec(), var_dec(), threadvar_dec() and consts_dec() all return whether they had encountered a "generic" token that was followed by one of $
pdecobj.pas:
* extend method_dec() to take a parameter that says whether the method is supposed to be a generic one
* parse_object_members: while read_record_fields() can handle "generic" we also need to handle the case of "generic" if no fields are allowed anymore
psub.pas:
* extend read_proc() by the possibility to tell it that the procedure/function to be parsed is supposed to be generic
* adjust read_declarations() and read_interface_declarations() to keep track of parsed "generic" tokens and to pass them on accordingly
ptype.pas:
* parse_record_members: same remark as for pdecobj.parse_object_members
git-svn-id: trunk@32380 -
pexpr.pas:
+ new enum texprflag and corresponding set texprflags
* comp_expr: replace accept_equal and typeonly with texprflags parameter
* factor: replace typeonly and hadspecialize with texprflags parameter
* sub_expr: replace accept_equal and typeonly with texprflags parameter
* adjust calls to comp_expr(), factor() and sub_expr()
other units:
* adjust calls to comp_expr(), factor() and sub_expr()
git-svn-id: trunk@32269 -
ptype.pas, resolve_forward_types:
* in case of the def of the forward being the same as the genericdef of the def the forwarddef belongs to the typesym needs to be changed to the one of the specialization
tests/webtbs/tw28674.pp:
* adjusted text
git-svn-id: trunk@31987 -
ptype.pas, resolve_forward_types:
* fix an access violation in case of inline pointer declarations
* fix the check whether it's a valid use of a generic (parse_generic is useless here...)
+ added test
git-svn-id: trunk@31910 -
* for now all typesyms are created as registered
Note: an additional parameter instead of an overload is used for ttypesym.create as otherwise both constructors would need to be overridden in potential descendant CPU-specific classes...
git-svn-id: trunk@31591 -
(abstract)recordsymtables, so that these settings don't depend on the
current user settings when internally creating record definitions
git-svn-id: branches/hlcgllvm@30343 -
type
TTestLongInt = specialize SomeOtherUnit.TTest<LongInt>;
will now have to read as
type
TTestLongInt = SomeOtherUnit.specialize TTest<LongInt>;
While this is not backwards compatible this situation should arise seldomly enough and the benefits especially in context with generic functions/procedures/methods outway the drawbacks.
pbase.pas:
* try_consume_unitsym: add a allow_specialize parameter that allows to parse "specialize" in front of a non-unit symbol; whether it was a specialization or not is reported using a new is_specialize parameter
+ add a new overload try_consume_unitsym_no_specialize that calls try_consume_unit sym with allow_specialize=false and a dummy is_specialize parameter
* switch calls to try_consume_unitsym to try_consume_unitsym_no_specialize
pstatmnt.pas, try_statement:
* switch call to try_consume_unitsym to try_consume_unitsym_no_specialize
* adjust call to parse_nested_types
ptype.pas:
+ extend id_type with the possibility to disallow unit symbols (needed if a specialize was already parsed) and to report whether a specialize was parsed
+ extend parse_nested_types with the possibility to tell it whether specializations are allowed
* have parse_nested_types specialize generic defs if one is encountered and local type defs are allowed
* id_type: only allow "unitsym.specialize sym" or "specialize sym", but not "specialize unitsym.sym"
* single_type: correctly handle specializations with "specialize" keyword
* read_named_type.expr_type: there is no longer a need to check for "specialize" keyword
pexpr.pas:
+ new function handle_specialize_inline_specialization which tries to specialize a type symbol
* handle_factor_typenode: handle specializations after a point that follows a record or object (why isn't this part of postfixoperators anyway? O.o)
* postfixoperators: handle "specialize" after records and objectdefs
* factor_read_id: handle "specialize" in front of an identifier (and after unit symbols)
+ added tests
* adjusted test webtbs/tw16090.pp
git-svn-id: trunk@29768 -
ptype.pas, id_type:
* don't generate an error if the undefineddef typesym is an explicit rename that belongs to a generic
+ added test
git-svn-id: trunk@29485 -
"reference to ...; cdecl;". The "reference to ..." syntax is what Delphi
uses for anonymous function references. The "cdecl;" indicates that this
is for the C-variant of such references, which is what blocks are
git-svn-id: branches/blocks@28233 -
o blocks are implemented as a variation of procedure variables
o declaration of a block variable: "test: procedure(c: char) is block;"
(C equivalent: (void)(^test)(char c) )
o the compiler automatically converts procedures/functions whose address
is passed to a block parameter or assigned to a block variable into
a "block". This consists of
1) generating a block descriptor (containing the size of the "block
literal" (see below) and the signature of the invocation function
encoded as an Objective-C selector)
2) generating a wrapper function around the original funcion (with C
calling convention), that has an extra first hidden parameter
(marked as vo_is_parentfp in the compiler) whose type is a pointer
to the describing "block literal"
3) generating the "block literal", which contains a pointer to an
external variable indicating whether this block captures context or
not, some flags (see compiler/blockutl.get_block_literal_flags for
info), a pointer to the wrapper function and a pointer to the
descriptor. In the future, it will also contain captured variables.
o right now, only global procedures/functions can be converted to blocks
(because they don't require state capturing). The next steps are (Object
Pascal) methods (not Objective-C methods, because Objective-C method
procvars don't exist) and finally nested functions
o on Mac OS X, the functionality will only work on Mac OS X 10.7 and later,
because we have to use the so-called "ABI.2010.3.16" to ensure that
our blocks aren't called as variadic functions by the runtime (which
came out after the Mac OS X 10.6 release)
o while the currently implemented functionality does not require any
library support at all, there's no use enabling it on other platforms
because unless it has been confirmed to work with a blocks runtime,
there's no point in using blocks (they're just somewhat bulky procvars
right now). Enabling it on other platforms (in combination with the
GNUStep Objective-C run time), should simply be a matter of adding
the right {$linklib xxx} statement to rtl/inc/blockrtl.pp file, adding
that file to Makefile.fpc for that platform and adding that platform
to the compiler/systems.systems_blocks_supported set
git-svn-id: branches/blocks@28232 -
ptype.pas, read_named_type:
* array_dec & procvar_dec: set df_generic of the array/procvar if parse_generic was originally set
+ added test
git-svn-id: trunk@27874 -
ptype.pas:
* read_named_type: change hadtypetoken from a value to a var parameter and set it to false if a type helper is parsed so that calling code does not handle it as unique
* read_anon_type: handle that hadtypetoken is now a var parameter
pgenutil.pas, generate_specialization:
* handle that hadtypetoken of read_named_type is now a var parameter
+ added test
git-svn-id: trunk@27870 -
For partial specialization only the declaration is reparsed, but not method bodies.
The way generic parameters are passed around inside the compiler is changed: instead of creating new type symbols we keep a (name,def) pair so that the code in insert_generic_parameter_types can decide whether it needs to add a type symbol (for new undefined defs) or not (for real types and undefined defs that were passed on from the parent generic). This required the tfpobjectlist type of the genericlist variables/parameters to be changed to tfphashobjectlist.
For correctly parsing Delphi specializations as parameters in functions of records (or objects) the relationship between the def and its typesym must already be established during the parsing. For this the checks for forcing a "type is not completely defined" message needed to be adjusted to correctly handle nested types as well. This should as a sideeffect also allow the usage of nested constants, etc like was fixed for classes some months ago.
ToDo:
- if a generic is specialized with only fully defined types then we could generate the in the unit where it's used. This is not yet done.
- currently we don't specialize generics that are currently parsed; maybe this could be improved in the future for better type compatibility checks
- check whether the pausing of token recording for partial specializations works correct in context of hint modifiers
pgenutil.pas:
* parse_generic_parameters: return a tfphashobjectlist instead of a tfpobjectlist (requires a few type adjustments in various other declarations)
* maybe_insert_generic_rename_symbol, insert_generic_parameter_types: change genericlist from tfpobjectlist to tfphashobjectlist
* parse_generic_specialization_types_internal: use is_generic instead of checking for df_generic
* generate_specialization:
+ add a nested function to disable the requirement to check for method bodies
* use the "simple" parameter parsing only for error recovery
* instead of already creating a new type symbol for a parameter we use the found symbol's name and its def and maybe create it later on (therefor the type of tfpobjectlist was changed to tfphashobjectlist)
* a partial specialization is specialized into the symtable of the def it is specialized in instead of one of the two global symtables
* for now we handle partial specializations of generics we are currently parsing like before
* don't continue recording generic tokens while we do a partial specialization
* use the new unset_forwarddef function on the newly created defs
* insert_generic_parameter_types: only create a new type symbol if the found type symbol does not yet have an owner (thus was freshly created for this generic declaration)
pdecobj.pas, object_dec:
* change type of genericlist from tfpobjectlist to tfphashobjectlist
* set the type sym for all object types that can be generic or inside a generic (needed for correctly parsing Delphi style generic declarations)
pdecsub.pas, parse_proc_head:
* consume_generic_interface: always generate the specialization name as now all generics are "specialized" inside a generic
* the assumption that the def index numbers are the same is no longer true as the genericdef might contain the defs of partial specializations which are not generated for full specializations
pdecvar.pas, read_record_fields:
* we also need to check nested types whether they contain a not yet completely parsed record or object
ptype.pas:
* read_named_type:
* change genericlist from tfpobjectlist to tfphashobjectlist
* pass the typesymbol along to record_dec
* resolve_forward_types: use is_generic instead of checking for df_generic
* single_type:
* use is_generic instead of checking for df_generic
* no need to check generic parameters
* parse_record_members:
+ add parameter for the record's type symbol
* setup the typesym <=> def relationship
+ record_dec: add parameter for the type symbol and pass it to parse_record_members
* read_named_type, expr_type: use is_generic instead of checking for df_generic
* array_dec & procvar_dec: change genericlist from tfpobjectlist to tfphashobjectlist
symdef.pas, tstoreddef:
* improve the checks used in is_generic and is_specialization to really only work on true generics and true (and partial) specializations respectively
* don't search the type parameters in the symtable, but store them in the PPU and load them from there
- remove fillgenericparas method (including the calls in the descendants tarraydef, tprocvardef, tobjectdef and trecorddef)
defcmp.pas, compare_defs_ext:
* handle partial specializations: specializations with only undefineddefs are compatible to generic defs
pdecl.pas, types_dec:
* switch generictypelist from tfpobjectlist to tfphashobjectlist
ppu.pas:
* increase PPU version
+ added tests that ensure that "not completely defined" checks for records (and objects) still work correctly
git-svn-id: trunk@27861 -
