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

E0308 makes incorrect proposal on range reference, missing parantheses #73553

Closed
phorward opened this issue Jun 20, 2020 · 1 comment · Fixed by #73639
Closed

E0308 makes incorrect proposal on range reference, missing parantheses #73553

phorward opened this issue Jun 20, 2020 · 1 comment · Fixed by #73639
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. C-bug Category: This is a bug. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@phorward
Copy link

phorward commented Jun 20, 2020

Hi there!

With this code (here's a playground)

type Range = std::ops::Range<usize>;

fn demo(r: &Range) {
    println!("{:?}", r);
}

fn tell(x: usize) -> usize {
    x
}

fn main() {
    demo(tell(1)..tell(10)); // here, it is reported wrongly!
    demo(1..10); // here, it is reported correctly!
}

The compiler reports this error message with a hint

error[E0308]: mismatched types
  --> src/main.rs:13:10
   |
13 |     demo(tell(1)..tell(10)); // here, it is reported wrongly!
   |          ^^^^^^^^^^^^^^^^^
   |          |
   |          expected reference, found struct `std::ops::Range`
   |          help: consider borrowing here: `&tell(1)..tell(10)`
   |
   = note: expected reference `&std::ops::Range<usize>`
                 found struct `std::ops::Range<usize>`

but the hint is incorrect due to missing parantheses in this case. The correct answer would be

   |          help: consider borrowing here: `&(tell(1)..tell(10))`

It works correctly when the second line in main is executed, where the range is provided directly.

Meta

rustc --version --verbose:

1.44.1

This issue has been assigned to @ayazhafiz via this comment.

@phorward phorward added the C-bug Category: This is a bug. label Jun 20, 2020
@jonas-schievink jonas-schievink added A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 20, 2020
@ayazhafiz
Copy link
Contributor

@rustbot claim

@rustbot rustbot self-assigned this Jun 22, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 23, 2020
Change heuristic for determining range literal

Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.

Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.

A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in rust-lang#60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.

Closes rust-lang#73553
Manishearth added a commit to Manishearth/rust that referenced this issue Jun 24, 2020
Change heuristic for determining range literal

Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.

Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.

A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in rust-lang#60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.

Closes rust-lang#73553
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 24, 2020
Change heuristic for determining range literal

Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.

Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.

A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in rust-lang#60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.

Closes rust-lang#73553
@bors bors closed this as completed in 7930f9a Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix`. C-bug Category: This is a bug. D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants