Issue 1:
I stumbled upon this issue by accident, as I noticed that using a symbol that has been imported in multiple glob statements does not result in an error:

mod foo {
pub fn p() { println("foo"); }
}
mod bar {
pub fn p() { println("bar"); }
}

mod baz {
use foo::*;
use bar::*;
#[main]
fn my_main() {
p();
}
}

A simple oversight, I thought, and dove into resolve to fix the bug. Then I noticed that not even single imports are checked for conflicts:

mod foo {
pub fn p() { println("foo"); }
}
mod bar {
pub fn p() { println("bar"); }
}

mod baz {
use foo::p;
use bar::p;
#[main]
fn my_main() {
p();
}
}

I assumed that the reason for this was that currently both glob and single imports are flattened into a hashmap per module and tried to introduce a 2-level import scheme that allows duplicates only in glob imports but not in single imports.

And then I noticed that it's possible to export glob imports from a crate, making that scheme impossible. Even worse: this makes the global API of a crate dependent on the vigilance of the developer to not export multiple symbols with the same name, as a simple rearranging of use statements in the source code could break existing users of the crate.

So, there are four possible ways to go about this problem:

Don't change anything. I.e. don't check for duplicate imported symbols, neither single imports nor glob imports. (Maybe add a lint, but that would probably have to be turned of in many cases, e.g. libstd is full of duplicate glob imports).

Disallow duplicate imports, even when glob importing. This is IMO not workable.

Disallow exporting glob imports from crates, making the aforementioned 2-level duplicate checking possible (i.e. disallow duplicate single imports, disallow used duplicate glob imports, allow unused duplicate glob imports).

A variant on 3): allow exporting glob imports, implement the 2-level scheme for imports that are not visible from outside the crate, but disallow any duplicate imports otherwise.

or 4) would be my preferred solution, but would incur a lot of work, both in implementing the scheme and restructuring existing code. 1) is the most realistic solution, but I personally don't really like it, as Rust is all about safety after all.

Fun example at the end:

mod foo {
pub fn p() { println("foo"); }
}
mod bar {
pub fn p() { println("bar"); }
}

mod baz {
use bar::p;
use foo::*;
#[main]
fn my_main() {
p();
}
}

Here, the use foo::*; is marked as being unused, even though when running the program, foo::foo() is actually the implementation of foo() that is used.

Issue 2:
I got an internal compiler error when cargo testing my code, and I was unfortunately unable to reproduce on a small sample. The code is here on Github, to reproduce the error, change the literal on one line in test from 42.0 to 42.

$ rustc --version --verbose
rustc 1.0.0-nightly (522d09dfe 2015-02-19) (built 2015-02-21)
binary: rustc
commit-hash: 522d09dfecbeca1595f25ac58c6d0178bbd21d7d
commit-date: 2015-02-19
build-date: 2015-02-21
host: i686-unknown-linux-gnu
release: 1.0.0-nightly
$ RUST_BACKTRACE=1 cargo test --verbose
Compiling spiral v0.0.1 (file:///[...]/spiral)
Running `rustc src/main.rs --crate-name spiral --crate-type bin -g --test -C metadata=1ade813d3d860ac1 -C extra-filename=-1ade813d3d860ac1 --out-dir [...]/spiral/target --emit=dep-info,link -L dependency=[...]/spiral/target -L dependency=[...]/spiral/target/deps`
error: internal compiler error: Impl DefId { krate: 2, node: 74181 } was matchable against Obligation(predicate=Binder(TraitPredicate(core::cmp::PartialEq<_>)),depth=1) but now is not
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:189

stack backtrace:
1: 0xb7231280 - sys::backtrace::write::hb58c665617e5cee2KlC
2: 0xb725b8b0 - panicking::on_panic::hd4d4fc652390cdd8tXL
3: 0xb7195ac0 - rt::unwind::begin_unwind_inner::h6797c7a781aac698RBL
4: 0xb5656fd0 - rt::unwind::begin_unwind::h13117811778590822301
5: 0xb5657800 - diagnostic::Handler::bug::h0b9167776bd8dc1aw4E
6: 0xb61b5310 - middle::traits::select::SelectionContext<'cx, 'tcx>::rematch_impl::h7f3f2e654c4ffad9kHU
7: 0xb61b4c30 - middle::infer::InferCtxt<'a, 'tcx>::try::h13523729267676866609
8: 0xb619dd90 - middle::traits::select::SelectionContext<'cx, 'tcx>::confirm_candidate::ha4efb7af28b19263S8T
9: 0xb61784f0 - middle::traits::select::SelectionContext<'cx, 'tcx>::select::h5394e35b0e7c70a6lhS
10: 0xb6174160 - middle::traits::fulfill::FulfillmentContext<'tcx>::select::hbef8233dc9336219B0P
11: 0xb6173ac0 - middle::traits::fulfill::FulfillmentContext<'tcx>::select_where_possible::hbd71b9b88c61613cHZP
12: 0xb6cdddc0 - check::vtable::select_fcx_obligations_where_possible::hffd3ec74dffa624eVRb
13: 0xb6d1a6f0 - check::FnCtxt<'a, 'tcx>::resolve_type_vars_if_possible::he1da80c3c9c1dda2rJo
14: 0xb6cca360 - check::structurally_resolved_type::hb6535b94e7bbe37bNPt
15: 0xb6e00220 - check::check_expr_with_unifier::h9614455191220309796
16: 0xb6dbad90 - check::check_expr_with_unifier::check_binop::hbf8de0ab08b2ba09JMq
17: 0xb6df3370 - check::check_expr_with_unifier::h6092115828992963581
18: 0xb6dd9240 - check::check_expr_with_unifier::h3884107362083173097
19: 0xb6dbad90 - check::check_expr_with_unifier::check_binop::hbf8de0ab08b2ba09JMq
20: 0xb6df3370 - check::check_expr_with_unifier::h6092115828992963581
21: 0xb6df3370 - check::check_expr_with_unifier::h6092115828992963581
22: 0xb6dd9240 - check::check_expr_with_unifier::h3884107362083173097
23: 0xb6dd0200 - check::check_expr_with_unifier::check_then_else::h483da0d6a4f3eab2MEq
24: 0xb6decc20 - check::check_expr_with_unifier::h17365000147061483630
25: 0xb6da6d80 - check::check_block_with_expected::hf29cd5d4f1823991zys
26: 0xb6decc20 - check::check_expr_with_unifier::h17365000147061483630
27: 0xb6ccafe0 - check::_match::check_match::closure.29042
28: 0xb6ccac10 - check::_match::check_match::h77807f1365a779d3V1a
29: 0xb6decc20 - check::check_expr_with_unifier::h17365000147061483630
30: 0xb6da6d80 - check::check_block_with_expected::hf29cd5d4f1823991zys
31: 0xb6df9ad0 - check::check_expr_with_unifier::h14838318111108599859
32: 0xb6da6d80 - check::check_block_with_expected::hf29cd5d4f1823991zys
33: 0xb6d85a80 - check::check_fn::h9733b23b5bb31869JKn
34: 0xb6da3700 - check::check_bare_fn::hc0a904b0aabec0a4Wzn
35: 0xb6d9aa00 - check::check_item::heaa17bb09891b8a9nTn
36: 0xb6da19f0 - visit::walk_item::h334270929839752142
37: 0xb6da19f0 - visit::walk_item::h334270929839752142
38: 0xb6da19f0 - visit::walk_item::h334270929839752142
39: 0xb6e7f750 - check_crate::closure.35867
40: 0xb6e78b60 - check_crate::h74f1efb9c9ad0cecVjC
41: 0xb769c480 - driver::phase_3_run_analysis_passes::ha81485be033381d8gHa
42: 0xb7680c20 - driver::compile_input::h55e2c5089100dcc0Gba
43: 0xb7760430 - run_compiler::h7c1df0ae32ef6a57Zbc
44: 0xb775e810 - thunk::F.Invoke<A, R>::invoke::h4956589150906656218
45: 0xb775d680 - rt::unwind::try::try_fn::h3108213307196454525
46: 0xb72d5b30 - rust_try_inner
47: 0xb72d5b00 - rust_try
48: 0xb775d9b0 - thunk::F.Invoke<A, R>::invoke::h9387302087009601825
49: 0xb72474c0 - sys::thread::thread_start::hb380b1da46a95e5393G
50: 0xb2f29ea0 - start_thread
51: 0xb7049502 - clone
52: 0x0 - <unknown>

Could not compile `spiral`.

Caused by:
Process didn't exit successfully: `rustc src/main.rs --crate-name spiral --crate-type bin -g --test -C metadata=1ade813d3d860ac1 -C extra-filename=-1ade813d3d860ac1 --out-dir [...]/spiral/target --emit=dep-info,link -L dependency=[...]/spiral/target -L dependency=[...]/spiral/target/deps` (status=101)

I am sorry for such a crude report, but I could not come with a better sample, as the origin of the error is a bit unclear to me.