Loading ...
Sorry, an error occurred while loading the content.

279Re: [caplet] Code that lexes differently in ES3 vs ES3.1

Expand Messages
  • David-Sarah Hopwood
    Feb 10, 2009
    • 0 Attachment
      Brendan Eich wrote:
      > On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
      >
      >> From what I remember this started out as a bug in IE and then
      >> Firefox followed suit for compatibility which left the other
      >> browsers with no choice.
      >
      > No, other browsers followed suit first.
      >
      >> I can't find the original bug but `/[/]/` only started parsing in
      >> FF1.5, in FF1.0 it would throw a syntax error.
      >
      > https://bugzilla.mozilla.org/show_bug.cgi?id=309840

      <https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>

      # This fixes a highly dup'ed IE compatibility bug. It's an extension
      # to ECMA syntax that's allowed by Section 16. I'm approving it so
      # that we can get it into 1.8b5 / Firefox 1.5b2.

      As the example in my first post demonstrated, it is absolutely not
      correct that this was an allowed Section 16 extension. That section
      allows lexical extensions only if a program does not match the lexical
      grammar in the spec (in this case using the ES3 definition of
      RegularExpressionLiteral), and allows regexp syntax extensions only
      if the resulting RegularExpressionBody does not match Pattern.

      In fact this just makes me even more worried: it seems that Section 16
      is being misinterpreted in a way that prevents independently developed
      parsers, implemented strictly from the spec, from being able to match the
      parsing behaviour of browsers on syntactically valid ES3 code. Is this
      just a one-off mistake, or is Section 16 consistently being interpreted
      too loosely?

      --
      David-Sarah Hopwood ⚥
    • Show all 13 messages in this topic