Ticket #105 (closed enhancement: fixed)

Opened 10 months ago

Last modified 10 months ago

Improve handling of 'base' as a package name

Reported by: stephan Owned by: stephan
Priority: major Milestone: OTDT_1.1.9
Component: compiler Version: 1.1.8
Keywords: Cc:

Description

While generally, base is allowed as a package name, different parsing modes (normal, recovery, assist, diagnose) handle scanner states slightly different.

Added new 8.7.1-otjld-base-used-in-declaration-4 to witness a tricky situation where

  • import base must recognize base as a modifier
  • base.T871buid4 must interpret base as an identifier
  • subsequent playedBy must find the scanner in OT/J mode

Change History

Changed 10 months ago by stephan

  • status changed from new to closed
  • resolution set to fixed

Steps towards resolution:

  • when the parser starts over to enter recovery mode, the scanner state must be reset to allow reading base as an identifier. Fixed in r18152, which however caused regression in 8.1.1-otjld-non-roleclass-with-playedby-3: token playedBy was consumed before consumeClassHeaderName1() could put the scanner into OT/J mode, thus skipping the erroneous playedBy declaration. Previously this error was detected because in recovery mode the scanner was actually in OT/J mode from the beginning.
  • as a new strategy r18156 localizes more of the stateful scanning to the Scanner:
    • reading team is recorded by _teamKeywordSeen (old). This state does not yet enable OT/J keywords.
    • import base is specifically recognized by enabling base as a keyword based on the _atStartOfImport flag (old).
    • reading class or interface with _teamKeywordSeen==true invokes enterOTSource() thus setting _isOTSource (and resetting _teamKeywordSeen). In this state all OT/J keywords are enabled. It is important that this state change happens before the full class header is parsed, thus any playedBy or when/base when are scanned correctly (new).
  • Scanner state must be reset for recovery in two situations:
    • Parser.moveRecoveryCheckpoint() if new checkpoint is position 0 (done in r18151).
    • LexStream.<init>() if initial position (init) == 0 (done in r18156).

This should resolve this issue, unless tests show regression.

Note: See TracTickets for help on using tickets.