News for hackers. Stuff that matters.
Re:Constexpr-8cc: Compile-time C Compiler by kazinator on Friday November 18, 2016 @05:35PM (#12990646)
Here is another thing: each time they add this or that cruft to C++, the syntax for that tidbit has to go into the hard-coded grammar. For the past 30 years, they have been missing opportunity after opportunity to somehow make the language internally extensible, so that new rules don't have to be added any more to a hard-coded parser (but, say, defined by C++ programs themselves). So now, check this out, GNU C++ has a hand-written recursive-descent parser ... that is 1195625 characters of C. It's almost 40K lines just to scan some tokens and get an abstract syntax tree.

https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/cp

Re:Constexpr-8cc: Compile-time C Compiler by smallnamespace on Friday November 18, 2016 @06:52PM (#12991000)
At this point, is there any parser out there that could deal with C++'s grammar?

What you're suggesting is tantamount to throwing out C++'s current syntax, which will never happen, or taking the existing parser and making it even more complicated so that it supports extensions.

Re:Constexpr-8cc: Compile-time C Compiler by gpderetta on Friday November 18, 2016 @07:39PM (#12991214)
IIRC g++ had historically a machine generated parser (bison maybe?) But it got replaced around 3.0 time because the new hand written parser was faster and more maintainable.
Re:Constexpr-8cc: Compile-time C Compiler by kazinator on Friday November 18, 2016 @08:11PM (#12991390)
I think, you cannot beat beats shift-reduce LALR(1) with recursive descent on raw performance on a reasonable syntax. However, parsing C++ with LALR(1) will require unmaintainable hacks in the grammar. Recursive descent accomodates ad-hoc fudging much better than parser generation. In any given rule, you can look ahead as much as you want and invoke any Turing computation to decide the parse. Also, recursive descent approaches support backtracking fairly naturally: try it this way, as far ahead as necessary, or else start again, falling back on this. Let's see ...

  28374 /* Commit to the currently active tentative parse.  */
  28375 
  28376 static void
  28377 cp_parser_commit_to_tentative_parse (cp_parser* parser)
  28378 {
  28379   cp_parser_context *context;
  28380   cp_lexer *lexer;
  28381 
  28382   /* Mark all of the levels as committed.  */
  28383   lexer = parser->lexer;
  28384   for (context = parser->context; context->next; context = context->next)
  28385     {
  28386       if (context->status == CP_PARSER_STATUS_KIND_COMMITTED)
  28387         break;
  28388       context->status = CP_PARSER_STATUS_KIND_COMMITTED;
  28389       while (!cp_lexer_saving_tokens (lexer))
  28390         lexer = lexer->next;
  28391       cp_lexer_commit_tokens (lexer);
  28392     }
  28393 }
Bison supports GLR ("generalized LR") via some technique of forking the parser and trying alternatives in parallel, which seems related to this.
Re:Constexpr-8cc: Compile-time C Compiler by int_19h on Saturday November 19, 2016 @02:49AM (#12992509)
The problem with C++ grammar is that inside templates, things are too flexible at times. For example:

    template<bool> struct a_t;

    template<> struct a_t<true> {
        template<int> struct b {};
    };

    template<> struct a_t<false> {
        enum { b };
    };

    typedef a_t<sizeof(void*)==sizeof(int)> a;

    enum { c, d };
    int main() {
        a::b<c>d; // declaration or expression?
    }
It's a fun C++ IDE torture test, which few pass. One that does is Visual Studio - if you create a C++ project and set up both 32-bit and 64-bit build targets, you can flip between them, and see the syntax highlighting change on the line with the comment.
Re:Constexpr-8cc: Compile-time C Compiler by kazinator on Friday November 18, 2016 @08:13PM (#12991402)
Make it more complicated once (bite the proverbial bullet) and then stop, versus keep on creeping in complexity.