arya dradjica - Codeberg.org

If you have the time, perhaps consider switching DeclRule to annotate an existing token buffer instead of building its own. rustc takes the same approach (decl macros are parsed into...

I'm sorry, I think this is a bad idea. For the most part, TokenBuffers will be immutable. I don't think parsing from a token buffer should be a destructive operation. VecDeque can also cause a...

macro_export is weird because the macros always end up at the crate root. You can instead write pub use assert_tok_is; after the macro declaration; this will export it from the local module.

While this type is valuable, it will take ~32 bytes and will mess up function ABIs when used as -> Result<_, ParseError>. It can get in the way of inlining and stuff across a lot of code. One...

Nice, thanks for adding this!

This interface works with symbol_table, but under the hood, it requires every string to have a permanently fixed address. I know the resolve_with() API is inconvenient, but it will allow for...

Could you add a static assertion for this, maybe at the relevant use site in the declarative macros code?

I don't think matches_start() is consistent with the doc comment. Maybe leave start() and end() where they are and separately add the matches_* methods, with their own doc comments?

I checked out the output -- this is really cool :)

One day we can invent a cursed custom Vec that can track half-filled bytes in its len, that would be fun :D

In terms of bit-packing here, it feels simpler (and probably more efficient) to assign each form 4 bits and embed a None case within them. That would allow two new cases: an empty Expand...

General question about define_newtype_bitfield!: At first glance here, it looks like has_form2 and form1 here overlap. Ideally we could write the exact bits each bit-flag and bit-field is...

:D

If this source file needs to grow further, the parsing logic could probably be moved to a submodule.

Perhaps leave this as a Vec for simplicity until we can benchmark things.

"There is no colon between them." -- could you explain? Do you strip out the colon from the token buffer, or is the token retained but not assigned an ExpandForm?

Maybe encode this as the least significant bit of expand_i?

Why this default?

Broken doc link. I'm thinking about adding CI so we can catch such cases.

I'm not sure you need this ... jj automatically excludes itself.