Date: Sat, 24 Oct 2020 14:11:28 -0400
Richard the git I linked to below works but the source is a bit of a mess; to give you the broad strokes, these are the big changes that would be needed to parse string literals during constant evaluation, in case this were to be seriously considered:
The Parse and Sema libraries would need to be combined.
Some additional code added to the Lexer/Preprocessor (nothing in the hot path), similar to the functionality used to expand macros.
Some additional logic needed to add "metaparsed" Decls into template instantiations (setting up scopes etc.).
There may be issues when the user calls macros in the code strings (e.g. `__metaparse("int SOMEMACRO(foo) = 4")`) — I got crashes early on, added checks and diagnostics to address them, but they were needed in a number of strange spots so a more comprehensive consideration would be warranted.
Would be nice if diagnostics could point inside a string literal, e.g.
```
__metaparse("int i = missspelling;");
^ unknown identifier
```
It’s been awhile but I think that covers it.
> On Oct 24, 2020, at 1:35 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Sat, 24 Oct 2020 at 20:01, David Rector <davrec_at_[hidden]> wrote:
>>
>>
>>
>> On Oct 24, 2020, at 12:34 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Sat, 24 Oct 2020 at 19:17, David Rector via SG7 <sg7_at_[hidden]> wrote:
>>
>> # 3
>> I think only strings should be injectible. Get rid of fragments — they are a source of needless complexity. IIUC, Andrew proposes the ability to inject arbitary code strings via `|# … #|` syntax. E.g. `consteval { |# "private: int i = 42;" #| }` would inject a private `i` into the enclosing class context (and result in a parse error if not in a class).
>>
>>
>> That doesn't seem to be correct. The paper says that a |# ... #| is an
>> identifier splice, not an arbitrary string.
>>
>> I am under the impression that building injected code with just
>> strings or with just tokens is rather horrible
>> for implementations? For syntax validation and semantic analysis, most
>> likely. Token-soup-injection
>> as a possibility sure made our clang friends balk in Toronto.
>>
>>
>> What’s so horrible about the implementation? Here’s an old clang implementation, scroll down to the "metaparsing" part for examples:
>>
>> https://github.com/drec357/clang-meta
>
> Perhaps Mr. Smith could illuminate us.
The Parse and Sema libraries would need to be combined.
Some additional code added to the Lexer/Preprocessor (nothing in the hot path), similar to the functionality used to expand macros.
Some additional logic needed to add "metaparsed" Decls into template instantiations (setting up scopes etc.).
There may be issues when the user calls macros in the code strings (e.g. `__metaparse("int SOMEMACRO(foo) = 4")`) — I got crashes early on, added checks and diagnostics to address them, but they were needed in a number of strange spots so a more comprehensive consideration would be warranted.
Would be nice if diagnostics could point inside a string literal, e.g.
```
__metaparse("int i = missspelling;");
^ unknown identifier
```
It’s been awhile but I think that covers it.
> On Oct 24, 2020, at 1:35 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Sat, 24 Oct 2020 at 20:01, David Rector <davrec_at_[hidden]> wrote:
>>
>>
>>
>> On Oct 24, 2020, at 12:34 PM, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Sat, 24 Oct 2020 at 19:17, David Rector via SG7 <sg7_at_[hidden]> wrote:
>>
>> # 3
>> I think only strings should be injectible. Get rid of fragments — they are a source of needless complexity. IIUC, Andrew proposes the ability to inject arbitary code strings via `|# … #|` syntax. E.g. `consteval { |# "private: int i = 42;" #| }` would inject a private `i` into the enclosing class context (and result in a parse error if not in a class).
>>
>>
>> That doesn't seem to be correct. The paper says that a |# ... #| is an
>> identifier splice, not an arbitrary string.
>>
>> I am under the impression that building injected code with just
>> strings or with just tokens is rather horrible
>> for implementations? For syntax validation and semantic analysis, most
>> likely. Token-soup-injection
>> as a possibility sure made our clang friends balk in Toronto.
>>
>>
>> What’s so horrible about the implementation? Here’s an old clang implementation, scroll down to the "metaparsing" part for examples:
>>
>> https://github.com/drec357/clang-meta
>
> Perhaps Mr. Smith could illuminate us.
Received on 2020-10-24 13:11:33