Hitting the wall; what am I doing wrong?

Open
#288 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
cpp
Domain
compilers

Research direction

Start with parser_fwd.hpp and libs/parser.cpp around line 187, then reproduce the MSVC build from commit 2ef0a54 to observe the compilation hang. Investigate whether separate grammar compilation, AST shared_ptr attributes, or rule count explains the behavior; done would be a confirmed explanation or documented guidance.

Written by the indexing model from the issue text.

Description

Hitting the Wall when Compiling the Grammar

I've been developing a parser for a fractal renderer formula file. Things were progressing nicely as I started parsing larger and larger elements of the format until I seemingly hit a wall. As of commit 2ef0a54 on the formula-compiler repository, I can't seem to add any more rules or the compilation just hangs on msvc. Note that it doesn't error, it just seems to get stuck compiling. I don't see any high activity bars on my disk or my CPU, so I'm not sure what the compiler is doing. But it ran for many minutes and didn't finish compiling parser.cpp.

Separate Compilation?

The header parser_fwd.hpp made me think that I might be able to break my parser into multiple source files and reduce the pressure on template mechanisms. I had noticed that the compile time for the parser was increasing as I added more details into my parser, but I considered this normal, especially as I was building Debug. However, I tried my best to separate out a simple rule into a separate translation unit and was unsuccessful. GitHub Copilot gave it a try, but only flailed around for 30 minutes before I put it out of it's misery.

Is there a mechanism for separate compilation of parts of a grammar? None of the examples demonstrate separate compilation.

My AST is a Hierarchy of Node shared_ptrs

The documentation recommends using the synthesized attributes for rules, but there doesn't seem to be automatic attribute propagation to shared_ptrs as the attributes. Therefore I need semantic action builder functions to create the attribute in my AST from the attribute synthesized by the framework. Is this putting additional template pressure on the compiler?

How Does the Number of Rules Impact Compilation?

I can create local parsers, e.g. const auto alpha = char_('a', 'z') | char_('A', 'Z'); without rules and use them to build productions that generate AST nodes. I also have a bunch of rules (see parser.cpp line 187). Should I be preferring fewer rules to reduce template pressure on the compiler or are they the same cost as the local parsers?

Dominant language
C++
Stars
182
Forks
28
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from boostorg/parser

All issues in boostorg/parser

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.