Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simplify creating a parser from a token tree #15306

Closed
erickt opened this issue Jul 1, 2014 · 1 comment
Closed

simplify creating a parser from a token tree #15306

erickt opened this issue Jul 1, 2014 · 1 comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@erickt
Copy link
Contributor

erickt commented Jul 1, 2014

Syntax extensions are pretty painful to write. One of the main reasons is that the API is pretty messy. For example, this pattern is littered across multiple syntax extensions:

    let mut p = parse::new_parser_from_tts(cx.parse_sess(),
                                           cx.cfg(),
                                           tts.iter()
                                              .map(|x| (*x).clone())
                                              .collect());

But all that line noise is pretty unnecessary. It could be easily slimmed down to:

    let mut p = cx.new_parser_from_tts(tts);
@wycats
Copy link
Contributor

wycats commented Jul 1, 2014

👍

Sawyer47 added a commit to Sawyer47/rust that referenced this issue Jul 3, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 24, 2023
lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
fix: Fix `inline_const_as_literal` error when the number >= 10

## Description

### The Bug

This PR fixes a small bug in the IDE assistence (`inline_const_as_literal`). When the being-inlined constant is a number and it is greater than or equal to 10, the assistence inserts unexpected string `(0x...)` after the number itself. A simple example is followed:

Current `inline_const_as_literal` changes

```rs
const A: usize = 16;

fn f() -> usize {
    A  // inline the constant
}
```

into

```rs
const A: usize = 16;

fn f() -> usize {
    16 (0x10)
}
```

The bug originates from rust-lang#14925 & rust-lang#15306 . rust-lang#14925 added some unittests, but it just tested the number-inlining behavior when the number is `0`.

https://github.com/rust-lang/rust-analyzer/blob/50882fbfa204027c84753e6d51a1a12884dc1b19/crates/ide-assists/src/handlers/inline_const_as_literal.rs#L124-L138

And rust-lang#15306 modified the behavior of `Const::render_eval` and added the `(0x...)` part after the number (if the number >= `10`). Because of insufficient unittests in rust-lang#14925, changes about `Const::render_eval` in rust-lang#15306 introduced this bug with no CI failure.

### The Fix

I think `Const::render_eval` is intended for user-facing value displaying (e.g. hover) and not designed for `inline_const_as_literal`. To fix the bug, I defined a new function named `Const::eval`, which evaluates the value itself faithfully and simply and does nothing else.

## Thanks

Thanks `@roife` for your kind help. Your guidance helped me better understand the code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants