Nightly broke quote_tokens!(..., -1i32)?

[jsgf]

I have some code which uses rustc_internal macros for code generation.

This code:

let val: i32 = ...;
//...
quote_tokens!(ctxt, $val => $scope :: $tok,)

was working perfectly to generate branches of a match statement. However, since last night, if val = -1i32, then this fails with: "error: unexpected token: -1i32". It works fine if val is positive.

I can work around this by avoiding explicitly mentioning the constant -1:

quote_tokens!(ctxt, x if x == ($scope :: $tok as i32) => $scope :: $tok,)

This seems like a regression…

[jsgf]

Looks like this is the result of https://github.com/rust-lang/rust/commit/bfa66bb389ce1c7ce4aff09d1842b3428015bd4d. I presume this means that quote_tokens!(ctx, -1i32) should be generating an AST for a unary-negation operator with the constant - but perhaps that doesn’t work in a pattern matching context?

[nodakai]

Can rustc -Z ast-json or ast-json-noexpand be of any help to you?

[oli-obk]

This seems like a regression…

Yep, I’ll take care of it on monday. Sorry about that. Do you have a fully contained example (playpen maybe?) that I could use as a testcase?

[jsgf]

Thanks! I don’t have a standalone testcase on hand. I’ll see if I can put one together.

[jsgf]

Can rustc -Z ast-json or ast-json-noexpand be of any help to you?

This is a run time error, not a compile-time one, so I don’t think that would help much.

[oli-obk]

if you have a crate I can extract a minimal example myself

[jsgf]

It’s xdrgen on crates.io, and at github at https://github.com/jsgf/rust-xdr/commit/55a4bb4ff7a8ff565363363836d11e321cfa5326 (prior to my workaround hacks).

[oli-obk]

Oh, I think I found it… Contrary to what I thought, the compiler did in fact create signed ast literals… the circumstances are confusing to me, but apparently it did in matches, but only if those matches were created by quote_tokens.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.