Skip to content

Function signature probably shouldn't be reported if an argument type mismatch is 'trivial' #99635

Closed
@zesterer

Description

@zesterer

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:

error[E0308]: mismatched types
    --> analysis/src/infer.rs:1959:66
     |
1959 | ...                   .for_each(|(x, y)| self.derive_links(x, y, self_ty, ty_links, eff_links)),
     |                                               ------------ ^ expected struct `tao_util::index::Id`, found reference
     |                                               |
     |                                               arguments to this function are incorrect
     |
     = note: expected struct `tao_util::index::Id<(tao_syntax::Span, ty::Ty)>`
             found reference `&tao_util::index::Id<(tao_syntax::Span, ty::Ty)>`
note: associated function defined here
    --> analysis/src/infer.rs:1866:8
     |
1866 |     fn derive_links(
     |        ^^^^^^^^^^^^
1867 |         &mut self,
     |         ---------
1868 |         member: TyId,
     |         ------------
1869 |         ty: TyVar,
     |         ---------
1870 |         self_ty: Option<TyVar>,
     |         ----------------------
1871 |         ty_links: &mut HashMap<usize, TyVar>,
     |         ------------------------------------
1872 |         eff_links: &mut HashMap<usize, EffectVar>,
     |         -----------------------------------------
help: consider dereferencing the borrow
     |
1959 |                             .for_each(|(x, y)| self.derive_links(*x, y, self_ty, ty_links, eff_links)),
     |                                                                  +

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:

error[E0308]: mismatched types
    --> analysis/src/infer.rs:1959:66
     |
1959 | ...                   .for_each(|(x, y)| self.derive_links(x, y, self_ty, ty_links, eff_links)),
     |                                               ------------ ^ expected struct `tao_util::index::Id`, found reference
     |                                               |
     |                                               arguments to this function are incorrect
     |
     = note: expected struct `tao_util::index::Id<(tao_syntax::Span, ty::Ty)>`
             found reference `&tao_util::index::Id<(tao_syntax::Span, ty::Ty)>`
help: consider dereferencing the borrow
     |
1959 |                             .for_each(|(x, y)| self.derive_links(*x, y, self_ty, ty_links, eff_links)),
     |                                                                  +

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions