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 -