Skip to content

Add note when a function is called from a module like it's an object #30356

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

Closed
wants to merge 1 commit into from

Conversation

GuillaumeGomez
Copy link
Member

The following code:

use std::io;

fn main() {
    io.stdin();
}

Which prints out:

test.rs:5:5: 5:7 error: unresolved name `io` [E0425]
test.rs:5     io.stdin();

Some beginners had issues with this error because they didn't understood it, so I added an explanation which helps them to understand it better.

r? @pnkfelix
cc @Manishearth
cc @nagisa

expr.span,
PathSearch) {
Success(_) => {
help_msg = format!("A module called `{module}` is \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not

To reference an item from the {module} module, use {module}::{next_path_component}.

instead? It is shorter and more-to-the-point. Also this obviously should become a span_help.

E.g. for your case it would then look like this:

To reference an item from the io module, use io::stdin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

@nagisa
Copy link
Member

nagisa commented Dec 13, 2015

Tests?

}

resolve_error(self,
expr.span,
ResolutionError::UnresolvedName(&*path_name, &*msg));
if !help_msg.is_empty() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the help msg should be passed down to resolve_error? I think the rest of the file does help messages this way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I infer @Manishearth is referring to how a case like OnlyIrrefutablePatternsAllowedHere is handled; see linked code; following such a strategy would entail either changing the UnresolvedName variant, or adding a new variant that carries the necessary info... but nonetheless, it is probably a good suggestion, just to keep all the error reporting in one place...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind, it's the same for me. I'll just provide an Option as extra parameter and we're good to go.

@GuillaumeGomez
Copy link
Member Author

@nagisa: Since it doesn't add a new error code, is it really needed ? I can add one, but if there is already one for this, it'll be useless...

@Manishearth
Copy link
Member

There should always be tests. Error codes are orthogonal.

@Manishearth
Copy link
Member

To be clearer, notes should have tests too. If there is a test, update it to mention the note, otherwise create your own.

@GuillaumeGomez
Copy link
Member Author

PS: To add a "note" tested comment:

//~NOTE

@@ -3391,6 +3391,7 @@ impl<'a, 'tcx> Resolver<'a, 'tcx> {

self.record_candidate_traits_for_expr_if_necessary(expr);

expr.toto();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A test of mine, wasn't intended to get committed. Just ignore it please.

@GuillaumeGomez
Copy link
Member Author

@pnkfelix found a way to handle 2 of 4 cases with the following code. of this example:

mod a { mod b { fn f() -> i32 { 3 } } }

fn g1() -> i32 {
    a.b.f()
}

fn g2() -> i32 {
    a::b.f()
}

fn g3() -> i32 {
    a::b()
}

fn g4() -> i32 {
    a::b
}

fn main() {
    println!("g1: {} g2: {} g3: {}", g1(), g2(), g3());
}

I'll cherry-pick his work and try to handle the last case.

@pnkfelix
Copy link
Member

closing in favor of PR #30413 (where @GuillaumeGomez still gets attribution)

@pnkfelix pnkfelix closed this Dec 16, 2015
bors added a commit that referenced this pull request Dec 21, 2015
Add note when item accessed from module via `m.i` rather than `m::i`.

(I tried to make this somewhat future-proofed, in that the `UnresolvedNameContext` could be expanded in the future with other cases besides paths that are known to be modules.)

This supersedes PR #30356 ; since I'm responsible for a bunch of new code here, someone else should review it. :)
@GuillaumeGomez GuillaumeGomez deleted the span_note branch January 3, 2016 01:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants