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

First attempt at fixing #20591 #24818

Merged
merged 6 commits into from
May 12, 2015
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 19 additions & 12 deletions src/librustc_resolve/resolve_imports.rs
Original file line number Diff line number Diff line change
Expand Up @@ -618,7 +618,7 @@ impl<'a, 'b:'a, 'tcx:'b> ImportResolver<'a, 'b, 'tcx> {
namespace_name,
name_bindings.def_for_namespace(namespace));
self.check_for_conflicting_import(
&import_resolution.target_for_namespace(namespace),
&import_resolution,
directive.span,
target,
namespace);
Expand Down Expand Up @@ -755,7 +755,7 @@ impl<'a, 'b:'a, 'tcx:'b> ImportResolver<'a, 'b, 'tcx> {
// Continue.
}
Some(ref value_target) => {
self.check_for_conflicting_import(&dest_import_resolution.value_target,
self.check_for_conflicting_import(&dest_import_resolution,
import_directive.span,
*ident,
ValueNS);
Expand All @@ -767,7 +767,7 @@ impl<'a, 'b:'a, 'tcx:'b> ImportResolver<'a, 'b, 'tcx> {
// Continue.
}
Some(ref type_target) => {
self.check_for_conflicting_import(&dest_import_resolution.type_target,
self.check_for_conflicting_import(&dest_import_resolution,
import_directive.span,
*ident,
TypeNS);
Expand Down Expand Up @@ -885,24 +885,31 @@ impl<'a, 'b:'a, 'tcx:'b> ImportResolver<'a, 'b, 'tcx> {

/// Checks that imported names and items don't have the same name.
fn check_for_conflicting_import(&mut self,
target: &Option<Target>,
import_resolution: &ImportResolution,
import_span: Span,
name: Name,
namespace: Namespace) {
let target = import_resolution.target_for_namespace(namespace);
debug!("check_for_conflicting_import: {}; target exists: {}",
&token::get_name(name),
target.is_some());

match *target {
match target {
Some(ref target) if target.shadowable != Shadowable::Always => {
let msg = format!("a {} named `{}` has already been imported \
in this module",
match namespace {
TypeNS => "type",
ValueNS => "value",
},
let ns_word = match namespace {
TypeNS => "type",
ValueNS => "value",
};
span_err!(self.resolver.session, import_span, E0252,
"a {} named `{}` has already been imported \
in this module", ns_word,
&token::get_name(name));
span_err!(self.resolver.session, import_span, E0252, "{}", &msg[..]);
let use_id = import_resolution.id(namespace);
let item = self.resolver.ast_map.expect_item(use_id);
// item is syntax::ast::Item;
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I'd prefer a type annotation in code rather than in a comment.
(I won't block this PR on that nit; it's more a note for the future...)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I always feel so weirded out when just annotating the type is what forces an import. I went back and forth on that line, it felt strange to be the only line importing from syntax::map.

Just as a style note, I feel like it'd be easier to navigate the code if even more type annotations were placed, (or I had a IDE which could tell me the type on mouseover). But I'm sure the core team already knows the types of most of the functions, so it's unnecessary for them, and in fact, just extra noise.

Which way should I favour in general? I'm hesitant to break with the established style, but I feel it'd be helpful to the newer contributors to add a fair number of annotations.

Copy link
Member

Choose a reason for hiding this comment

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

DXR, which should be coming online soon, does type on mouse-over for most variables.

I'd probably remove the comment and not add an annotation, tbh - I think a programmer should probably expect the result of expect_item to be an Item.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Aye, but what kind of item? syntax ::map isn't even imported.

I know I had to open up a number of files side by side and carefully trace through struct and function definitions to pin down some types in this block. A simple type annotation or two would have saved me at least 10 minutes of tracking things down.

span_note!(self.resolver.session, item.span,
"previous import of `{}` here",
token::get_name(name));
}
Some(_) | None => {}
}
Expand Down
27 changes: 27 additions & 0 deletions src/test/compile-fail/double-import.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
#![feature(no_std)]
#![no_std]

Copy link
Member

Choose a reason for hiding this comment

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

Please add a comment explaining what is being tested to the test file

// This tests that conflicting imports shows both `use` lines
// when reporting the error.

mod sub1 {
fn foo() {} // implementation 1
}

mod sub2 {
fn foo() {} // implementation 2
}

use sub1::foo; //~ NOTE previous import of `foo` here
use sub2::foo; //~ ERROR a value named `foo` has already been imported in this module [E0252]

fn main() {}