The first two commits are the actual fix going into place, and the last is just dealing with the fallout in the rest of the compiler.
The test added in the first two commits had 0 failures before this patch, and if the glob imports were changed to explicit imports then the errors showed up. Due to this behavior, I figured that the desired behavior was for glob imports to not accidentally leak a lot of non-public imports/functions/types into other modules.
There was quite a lot of fallout, and it all passes `make check` locally, but I doubt that it will pass on all platforms because there's probably some guarded off thing I missed.
I plan on making another patch soon which changes the default level of `unused_imports` to `warn` which will hopefully reduce a lot of the `use` noise throughout. In conjunction with #5104, and a few minor fixes, I think that the default level of `warn` is actually really usable.
This removes all but 6 uses of `drop {}` from the entire codebase. Removing any of the remaining uses causes various non-trivial bugs; I'll start reporting them once this gets merged.
See issue #4869. I'm not quite sure what constitutes "consensus from the core team" (cf. discussion in the issue), but this at least demonstrates that the proposed change is pretty straightforward.
After this change, there are no new test failures. I've un-ignored the `to_str` vectors test; it's not at all obvious to me why it'd be problematic, and it passes on my Linux machine.
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
r? @graydon
Major changes are:
- replace ~[ty_param] with Generics structure, which includes
both OptVec<TyParam> and OptVec<Lifetime>;
- the use of syntax::opt_vec to avoid allocation for empty lists;
cc #4846
* replace the dual next() and get() calls with a single next() function
* drop one of the pointer members from the struct
* add a method for using the lazy iterator with a for loop
* replace the dual next() and get() calls with a single next() function
* drop one of the pointer members from the struct
* add a method for using the lazy iterator with a for loop
r?
#3406
Pretty straightforward. I'm using opaque pointers instead trying to get trans and core to agree on the types of the main function and crate map. One oddity is that this required changing the order of the `-lrustrt` argument to the linker in order to resolve `upcall_new_stack`. Linkers are mysterious.
r?
After this patch, macros declared in a module, function, or block can only be used inside of that module, function or block, with the exception of modules declared with the #[macro_escape] attribute; these modules allow macros to escape, and can be used as a limited macro export mechanism.
This pull request also includes miscellaneous comments, lots of new test cases, a few renamings, and a few as-yet-unused data definitions for hygiene.
Address #2281
```
-> % cat foo.rs
fn foo() -> int {
let bar = 10;
bad
}
```
```
-> % rustc foo.rs
foo.rs:4:4: 4:7 error: unresolved name: `bad`. Did you mean: `bar`?
foo.rs:4 bad
^~~
error: aborting due to previous error
```
The first commit fixes warnings about `pub use` imports because it can't be known whether those are actually used or not.
The second commit fixes using `#[level(unused_imports)]` style control over the emission of warnings. Before it looked like it only worked as a command-line flag.
