-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Function signature probably shouldn't be reported if an argument type mismatch is 'trivial' #99635
Comments
I took a stab at this in #99646, let me know what you think. Specifically, we now only highlight the single mismatched parameter: https://github.com/rust-lang/rust/pull/99646/files#diff-e60ae3276b7c8ae96680b146101fe6e91f5bd3240aac50d11f88fdf110daa4ae |
Based on the changes in the diff, this seems like it would be a big improvement, much appreciated! I also like that only the parameter in question is mentioned now. |
…-arg-label, r=estebank Only point out a single function parameter if we have a single arg incompatibility Fixes rust-lang#99635
Only highlight unmatchable parameters at the definition site Followup to rust-lang#136497 This generally results more focused messages in the same vein as rust-lang#99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given. r? `@compiler-errors`
Rollup merge of rust-lang#136583 - Jarcho:fn_ctxt2, r=compiler-errors Only highlight unmatchable parameters at the definition site Followup to rust-lang#136497 This generally results more focused messages in the same vein as rust-lang#99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given. r? `@compiler-errors`
I've been recently doing a large amount of refactoring on my compiler. Although this has broadly been a pleasant experience, recent diagnostic changes have put a little pressure on my scroll wheel. Diagnostics that I (and I think many others, even newcomers) would consider trivial can sometimes take up many dozens of lines of compiler output. I definitely appreciate the verbosity, but I don't think it's always called for (at least, by default). As an example, I recently encountered the following error message:
That's 31 lines of terminal output to inform me that I forgot a
*
. As I say, I do appreciate the verbosity! But in cases like this, where the compiler can determine that the mismatch is trivial and the intended result is obvious (i.e: dereference the reference), I feel that the compiler should omit some of the more verbose parts of the message, such as the signature of the function.I realise that this is, to some extent, bikeshedding: but there is a very real trade-off between the assistance provided by a compiler error and redundant information in the error message that makes the cycle of fixing error messages slower and more inconvenient.
In my view, an output like the following where the original signature has been omitted has a much better tradeoff between verbosity and the time required to read the message and get to the heart of what the compiler is suggesting:
I am happy to make a PR for this myself, but I've not worked on rustc diagnostics before and may need pointing to the relevant code.
The text was updated successfully, but these errors were encountered: