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 -
older GDB versions and code in fpdebug.pas should no longer use it. Instead,
it should use BreakpointInsert or WatchpointInsert for adding a breakpoint or
watchpoint and getting its ID.
git-svn-id: trunk@29750 -
in the gdb/mi interface, which fixes various features, such as showing a
popup window with the old and new value of the variable, when stopping on a
watch, etc.
git-svn-id: trunk@29749 -
* all breakpoint and watchpoint adding now go through TGDBController and use
the proper gdb/mi commands when compiled with the gdb/mi debugger
git-svn-id: trunk@29746 -
(can happen when using 'step into instruction' inside the assembly window)
* obtain the PC counter after a breakpoint has been hit (so that the assembly
window shows the current instruction immediately after hitting a breakpoint)
git-svn-id: trunk@29735 -
* Unit finalization executes arbitrarily large amount of code. Doing it when error occurred can cause
other errors, overwriting the original error information.
* Code that prints error message depends on everything and a kitchen sink (most notably, Unicode manager
and lineinfo unit). Running it after finalizing units can be successful only by coincidence.
* Last but not least, this sequence (ExitProc -> print RTE -> finalize units) is same as one used in Delphi.
git-svn-id: trunk@29733 -
It is required by SQL Server Native Client 2008 and later (when not set it raises: Datetime field overflow. Fractional second precision exceeds the scale specified in the parameter binding.)
I have used precision 3 (milliseconds), which is maximum precision returned by DecodeTime used in handling of TDataTime values.
git-svn-id: trunk@29719 -
IDE. Tested under Linux (Fedora 21 - x86_64, GDB 7.8.2). It is still disabled
by default on all platforms. To enable it, build a snapshot with:
FPMAKEOPT="--ignoreinvalidoption --GDBMI=1"
Known issue: the GDB window in the IDE causes crashes, so don't open it :)
(for debugging purposes, set the environment variable FPIDE_GDBLOG=1 when
running the IDE and it will log everything in gdblog.txt)
git-svn-id: trunk@29716 -
