Skip to content

When a help message is associated with a warning message, the two message you should be printed together and the source code printed only once. #21938

Closed

Description

@dzamlo

For exemple, for the following code:

extern crate libc;

fn main() {
}

The output of rustc is:

bar.rs:1:1: 1:19 warning: use of unstable library feature 'libc'
bar.rs:1 extern crate libc;
         ^~~~~~~~~~~~~~~~~~
bar.rs:1:1: 1:19 help: add #![feature(libc)] to the crate attributes to silence this warning
bar.rs:1 extern crate libc;
         ^~~~~~~~~~~~~~~~~~

It should be:

bar.rs:1:1: 1:19 warning: use of unstable library feature 'libc'
bar.rs:1:1: 1:19 help: add #![feature(libc)] to the crate attributes to silence this warning
bar.rs:1 extern crate libc;
         ^~~~~~~~~~~~~~~~~~

I don't know if there is any help message associated with an error message, but if this the case, the same issue apply.

Activity

  1. added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Feb 21, 2015
  2. caipre commented on May 9, 2015

    @caipre
    Contributor

    Looks like the referenced merge addresses error + help combos (albeit not in the order described above):

    $ echo 'mod foo;' > test.rs
    $ rustc ./test.rs
    test.rs:1:5: 1:8 error: file not found for module `foo`
    test.rs:1 mod foo;
                  ^~~
    test.rs:1:5: 1:8 help: name the file either foo.rs or foo/mod.rs inside the directory ""

    But this still happens for error + warning combos:

    use std::vec::Drain;
    
    fn main () {
    }
    $ rustc ./test.rs
    ./test.rs:1:5: 1:20 error: use of unstable library feature 'collections': recently added as part of collections reform 2
    ./test.rs:1 use std::vec::Drain;
                    ^~~~~~~~~~~~~~~
    ./test.rs:1:5: 1:20 warning: unused import, #[warn(unused_imports)] on by default
    ./test.rs:1 use std::vec::Drain;
                    ^~~~~~~~~~~~~~~
    error: aborting due to previous error

    Though this may be deliberate since the error and warning are about different issues.

  3. carols10cents commented on Feb 2, 2016

    @carols10cents
    Member

    (albeit not in the order described above):

    So since helps look like they're a subdiagnostic of errors, and errors get output before their subdiagnostics, the ordering looks intentional.

    With the error+warning case, I think those are actually two separate diagnostics, that is, the warning is not the subdiagnostic of the error, so they shouldn't be combined.

    Sooo I think this issue might be done? If I'm understanding the intentionality of the current error display?

  4. removed
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Jun 27, 2016
  5. brson commented on Jun 27, 2016

    @brson
    Contributor

    Warnings have undergone a lot of churn lately, and some of them have been grouped together in logical ways. @jonathandturner @nikomatsakis @nrc @pnkfelix is this issue still relevant?

  6. pnkfelix commented on Jul 4, 2016

    @pnkfelix
    Contributor

    I think we can close this. The main redundancy has been addressed, and I think the current handling of help messages works at least for the case described

  7. nikomatsakis commented on Aug 23, 2016

    @nikomatsakis
    Contributor

    Agreed.

  8. added 2 commits that reference this issue on Apr 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lints

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions