Stream: t-compiler/rust-analyzer

Topic: Macro error when using negative literals


weegee (Oct 23 2020 at 10:57, on Zulip):

From this issue https://github.com/rust-analyzer/rust-analyzer/issues/6292 I would like to pick this one up. Any directions or head starts?

Florian Diebold (Oct 23 2020 at 11:24, on Zulip):

I'm pretty sure the error means that the macro didn't expand fully, and my guess as to why would be that -1.0 doesn't get matched as a literal because (I'm guessing) it probably gets parsed as two tokens which would form a unary expression

Jonas Schievink [he/him] (Oct 23 2020 at 11:26, on Zulip):

Yeah, according to the spec $x:literal should match "-? LiteralExpression" https://doc.rust-lang.org/reference/macros-by-example.html#metavariables

weegee (Oct 23 2020 at 11:31, on Zulip):

so it gets parsed as two tokens one - and other 1.0 right? (When it should be a single literal -1.0) So where's the parsing for literals done?

Florian Diebold (Oct 23 2020 at 11:35, on Zulip):

it's correct that it's being parsed that way, probably our definition of a literal fragment is wrong (according to what Jonas wrote)

Florian Diebold (Oct 23 2020 at 11:37, on Zulip):

I think the relevant code is this function, which implements literals as just parsing a single literal token

Florian Diebold (Oct 23 2020 at 11:38, on Zulip):

instead, literal will probably need to be a FragmentKind and handled by expect_fragment

weegee (Oct 23 2020 at 14:53, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/81609960fa30ea92e37b23dc7b025d1939626812/crates/parser/src/lib.rs#L99 I saw this, do I have to include some seperate variants to proceed?

Florian Diebold (Oct 23 2020 at 15:22, on Zulip):

@weegee yeah, I think you'll need to add a new function to grammar::fragments that first parses an optional -, and then a literal (atom::literal)

Last update: Jul 28 2021 at 04:00UTC