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 -
