allow negative numeric literals in concat!

[Ezrashaw]

Fixes #106837

While technically negative numeric literals are implemented as unary operations, users can reasonably expect that negative literals are treated the same as positive literals.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

The implementation looks fine, but given that this is technically a standard library macro, I think this needs @rust-lang/libs-api weigh-in too.

[dtolnay]

Something is screwed up in the following case:

macro_rules! negative {
    ($literal:literal) => {
        concat!(-$literal)
    };
}

fn main() {
    let string = negative!(1);
    println!("{:?}, {}", string, string.len());

    let string = negative!(-1);
    println!("{:?}, {}", string, string.len());
}

"-1", 2
"", 0

[Ezrashaw]

@dtolnay Fixed, this issue also occurred for the general case concat!(--1). I've also added this to the UI test.

We're looking for UnaryOp::Negation(IntegerLiteral) (which is effectively a negative integer literal). I wasn't correctly handling UnaryOp::Negation(SomeOtherExpression) properly.

Oh, and in terms of having a FCP, this is really, IMO, a bugfix. People can reasonably expect this to work.

@rustbot ready

[dtolnay]

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[AaronKutch]

What would be the interaction with concat! if #108385 were to be fixed? Would/should only literals supported by normal Rust still work?

[Ezrashaw]

@AaronKutch I'm definitely not an expert with this part of the compiler (I just fixed the bug), so take this with a grain of salt:

Only valid literals are/will be allowed, concat! is effectively a proc-macro implemented by the compiler (with the compiler's own unstable interfaces which are different from the stable proc_macro crate). This PR doesn't touch the lexer or literal validation at all; it just expands, and fixes a bug, with the input tokens that are allowed. Effectively, I think that user macros have a different definition of literals and thus aren't touched by this change.

@dtolnay Maybe you could add on to this? Thanks!

[dtolnay]

Yeah I don't immediately see how that issue is relevant to this PR.

[bors]

📌 Commit 41856b0 has been approved by dtolnay

It is now in the queue for this repository.

[compiler-errors]

@Ezrashaw was closing this PR intentional?

[Ezrashaw]

No, [insert swear word here]. Can I reopen it safely?

[compiler-errors]

Yes, though you deleted the branch, so you may need to open a new PR.

[Ezrashaw]

Fingers crossed. It's ok?

[compiler-errors]

@bors r=dtolnay

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Evaluate place expression in PlaceMention #104844

[bors]

📌 Commit 41856b0 has been approved by dtolnay

It is now in the queue for this repository.

[Ezrashaw]

Brilliant, thanks for the help.