|
| 1 | +bpp (0.7.0) unstable; urgency=medium |
| 2 | + |
| 3 | + * bpp: Added typeof operator: Returns a pointer's class name as a |
| 4 | + string |
| 5 | + * Dynamic casts: return nonzero exit code if the cast fails under any |
| 6 | + circumstances |
| 7 | + * bpp: Allow dynamic_casts to resolve the target class dynamically at |
| 8 | + runtime |
| 9 | + With this update: |
| 10 | + - @dynamic_cast<$shell_var> and @dynamic_cast<@object.reference> are |
| 11 | + now valid syntax |
| 12 | + - If a shell variable or object reference are given as the target |
| 13 | + 'cast-to' class, the compiler will expect to resolve the class type |
| 14 | + at runtime |
| 15 | + - @dynamic_cast<ClassName> is still absolutely valid syntax, |
| 16 | + however, ClassName being invalid will no longer result in a syntax |
| 17 | + error, but will instead give a warning that 'ClassName' does not |
| 18 | + refer to any known class and that the cast may fail at runtime |
| 19 | + * Error reporting overhaul: Better and more conscious UTF8 handling |
| 20 | + Removed the 'position_unknown' checks; we no longer have to deal |
| 21 | + with unknown positions now that we're not relying on ANTLR's built- |
| 22 | + in position tracking |
| 23 | + Separation of concerns: moved padding, etc, utf8 procedures to |
| 24 | + helper functions rather than complicating things by inlining |
| 25 | + everything |
| 26 | + * Bug fix in entity resolution: Declare all temporary variables local |
| 27 | + if possible |
| 28 | + If we're inside a class, a supershell, or bash function, it's |
| 29 | + possible for us to declare all temporary variables 'local', and we |
| 30 | + absolutely should |
| 31 | + This fixes a bug with nested object references. For example, |
| 32 | + @this.member=@(echo @this.member and then some) |
| 33 | + If the temporary variables necessary to access this.member are not |
| 34 | + declared local, then: |
| 35 | + - The pre-code necessary to access this.member precedes that |
| 36 | + assignment statement |
| 37 | + - Then, we enter the supershell in the rvalue of the assignment |
| 38 | + statement, which also contains a reference to this.member |
| 39 | + - So, once again we generate the pre-code necessary to access it, we |
| 40 | + access it, |
| 41 | + - AND THEN we execute the post-code necesary to clear the memory |
| 42 | + - That memory having been cleared, we return from the supershell |
| 43 | + context to the broader assignment statement |
| 44 | + And we find that we no longer know where to put the rvalue. |
| 45 | + The variables which told us how to access this.member have been |
| 46 | + cleared from inside the supershell. |
| 47 | + If we declare all temporary variables local however, then the pre- |
| 48 | + and post-code within the supershell is entirely isolated from the |
| 49 | + pre- and post-code of the surrounding assignment statement. |
| 50 | + * STL: Added Typed versions of arrays, stacks and queues |
| 51 | + With our new dynamic cast semantics permitting runtime |
| 52 | + evaluation of the target (casted) type, runtime type restrictions |
| 53 | + become enforceable and typed containers such as these become |
| 54 | + possible |
| 55 | + * STL: Added TypedShared classes: Shared (concurrency-safe) data |
| 56 | + structures with runtime type enforcement on their elements |
| 57 | + * bpp-lsp: Wrap program parsing in try-catch |
| 58 | + No need to crash if there's a ParseCancellationException etc. |
| 59 | + The lexer & parser still need a full rewrite. |
| 60 | + * bpp-lsp: ProgramPool: Verify parsing was successful before changing |
| 61 | + pool state |
| 62 | + This prevents crashes which may come from storing 'nullptr' parse |
| 63 | + results in the program pool's state, and later (unthinkingly) using |
| 64 | + them as if they were valid pointers. It also prevents us from losing |
| 65 | + diagnostic information about programs which have been parsed, which |
| 66 | + have also undergone incomplete updates that can't yet be fully |
| 67 | + re-parsed. |
| 68 | + * bpp-lsp: Keep state AND snapshot of state |
| 69 | + This eliminates any slight possibility for race conditions, where |
| 70 | + one thread may jump the queue and access an element of the |
| 71 | + ProgramPool's state while another thread is simultaneously modifying |
| 72 | + it |
| 73 | + |
| 74 | + -- rail5 < [email protected]> Mon, 18 Aug 2025 22:45:57 +0800 |
| 75 | + |
1 | 76 | bpp (0.6.2) unstable; urgency=medium |
2 | 77 |
|
3 | 78 | * Error reporting: Highlight error string in red & underline |
|
0 commit comments