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

this function takes 1 parameter but 3 parameters were supplied: defined here points to the wrong place. #44638

Closed
dpc opened this issue Sep 16, 2017 · 2 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug.

Comments

@dpc
Copy link
Contributor

dpc commented Sep 16, 2017

rustc output must have changed, and now every time I compile my code and call a method with a wrong number of arguments, Vim will jump to the definition of the function that is called incorrectly, and not the place where it is being called.

It seems to me that the output of the compiler is wrong in the first place: the main error file:line message should point to the broken code, not the definition of the function that is called (which is useful, but secondary). Ideally, I'd like rust.vim to be able to display both in the compilation error list, so I opened: rust-lang/rust.vim#174 there as well.

@TimNN
Copy link
Contributor

TimNN commented Sep 17, 2017

I experimented a bit on the playground:

  • the main error location is always given for the line of the caller
  • if caller and definition locations are in the same file, the order in which they are displayed depends on their order in that file

I believe that this is an issue purely with rust-lang/rust.vim.

@Mark-Simulacrum Mark-Simulacrum added A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. labels Sep 18, 2017
@estebank
Copy link
Contributor

I'm closing this ticket as this falls entirely under rust-lang/rust.vim#174. We'll keep the compiler output as it is (at least for now) as it seems to me that keeping labels in the same order as the code is more intuitive when looking at the error message. Tools that use the compiler output should differentiate between primary and secondary spans.

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 C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

4 participants