Currently, a decent parser definition yields fairly large structure like below:
Since many parsers are inherently empty (e.g. eol, eoi, eps, etc.), we can apply comprehensive optimization to all core parsers.
Background
I once tried to optimize the layout by applying [[no_unique_address]] on basic parsers. For example:
|
// TODO: [MSVC 2022 BUG] "overruns" in constexpr, test case in `lit.cpp` |
|
/*IRIS_NO_UNIQUE_ADDRESS*/ Left left; |
|
/*IRIS_NO_UNIQUE_ADDRESS*/ Right right; |
However, at the time of above change, MSVC 2022 had a serious bug where the existence of overlapping empty fields leads to invalid codegen (!) and emits nasty error on constexpr context.
As our minimum compiler requirement has been bumped to MSVC 2026, I think we can try to optimize the classes now. We need to check all parsers to see where we can apply such optimizations.
Currently, a decent parser definition yields fairly large structure like below:
Since many parsers are inherently empty (e.g.
eol,eoi,eps, etc.), we can apply comprehensive optimization to all core parsers.Background
I once tried to optimize the layout by applying
[[no_unique_address]]on basic parsers. For example:x4/include/iris/x4/core/parser.hpp
Lines 166 to 168 in 9dca36a
However, at the time of above change, MSVC 2022 had a serious bug where the existence of overlapping empty fields leads to invalid codegen (!) and emits nasty error on constexpr context.
As our minimum compiler requirement has been bumped to MSVC 2026, I think we can try to optimize the classes now. We need to check all parsers to see where we can apply such optimizations.