Before it wouldn't warn about unused imports in the list if something in the list was used. These commits fix that case, add a test, and remove all unused imports in lists of imports throughout the compiler.
Before, if anything in a list was used, the entire list was considered to be
used. This corrects this and also warns on a span of the actual unused import
instead of the entire list.
Impose a limit so that the typo suggester only shows reasonable
suggestions (i.e. don't suggest `args` when the error is `foobar`).
A tiny bit of progress on #2281.
r? @nikomatsakis The typechecker previously passed around a boolean return flag to
indicate whether it saw something with type _|_ (that is, something
it knows at compile-time will definitely diverge) and also had some
manual checks for the `ty_err` pseudo-type that represents a previous
type error. This was because the typing rules implemented by the
typechecker didn't properly propagate _|_ and ty_err. I fixed it.
This also required changing expected error messages in a few tests,
as now we're printing out fewer derived errors -- in fact, at this
point we should print out no derived errors, so report any that
you see (ones that include "[type error]") as bugs.
The typechecker previously passed around a boolean return flag to
indicate whether it saw something with type _|_ (that is, something
it knows at compile-time will definitely diverge) and also had some
manual checks for the `ty_err` pseudo-type that represents a previous
type error. This was because the typing rules implemented by the
typechecker didn't properly propagate _|_ and ty_err. I fixed it.
This also required changing expected error messages in a few tests,
as now we're printing out fewer derived errors -- in fact, at this
point we should print out no derived errors, so report any that
you see (ones that include "[type error]") as bugs.
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
r? @graydon
This removes `log` from the language. Because we can't quite implement it as a syntax extension (probably need globals at the least) it simply renames the keyword to `__log` and hides it behind macros.
After this the only way to log is with `debug!`, `info!`, etc. I figure that if there is demand for `log!` we can add it back later.
I am not sure that we ever agreed on this course of action, though I *think* there is consensus that `log` shouldn't be a statement.
Macro invocations with path separators (e.g. foo::bar!()) now produce a sensible error message, rather than an assertion failure. Also added compile-fail test case.
Fixes#5218 ?
The fix is straight-forward, but there are several changes
while fixing the issue.
1) disallow `mut` keyword when making a new struct
In code base, there are following code,
```rust
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
```
This is because of structural record, which is
deprecated corrently (see issue #3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.
2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.
Misc. issues
There is an ambiguity between empty struct vs. empty match stmt.
with following code,
```rust
match x{} {}
```
Two interpretation is possible, which is listed blow
```rust
match (x{}) {} // matching with newly-constructed empty struct
(match x{}) {} // matching with empty enum(or struct) x
// and then empty block
```
It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs
All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.
```rust
enum what { }
fn match_with_empty(x: what) -> ~str {
match (x) { //use parentheses to remove the ambiguity
}
}
```
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.
values to be copied. Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.
Fixes#4821.
The first commit message has most of the comments, but this pull request basically fixes a lot of issues surrounding the `unused_imports` warning/deny attribute.
Before this patch there were these problems:
1. Unused imports from `prelude.rs` were warned about with dummy spans, leading to a large number of confusing warnings.
2. Unused imports from `intrinsic.rs` were warned about with the file `<intrinsic>` which couldn't be forced to go away
3. Methods used from imported traites (like `io::WriterUtil`) resulted in an unused warning of the import even though it was used.
4. If one `use` statement imported N modules, M of which weren't used, M warning statements were issued.
5. If a glob import statement was used, each public export of the target module which wasn't used had a warning issued.
This patch deals with all these cases by doing:
1. Ignore unused imports from `prelude.rs` (indicated by a dummy span of 0)
2. Ignore unused imports from `intrinsic.rs` (test on the imported module name, is there a better way?)
3. Track when imported modules are used as candidates for methods, and just assume they're used. This may not end up being the actual case, but in theory not warning about an unused thing is worse than warning about a used thing.
4. Only issue one warning statement
5. Only issue one warning statement.
This is the first time I've edited the compiler itself, and I tried to keep up with the style around, but I may have missed something here or there...
1. Don't warn about anything not used in the prelude which is autmoatically
injected, accomplished with a test that the span is equal to a dummy span.
2. Don't warn about unused imports from the injected intrinsic module,
accomplished by testing against the name of the imported module
3. If anything is used from a glob import, don't warn about the glob import.
4. If an import imports more than one thing, and none of them are used, only
issue a warning once
Also updated the unused-imports-warn test to have stricter requirements on
error messages.
LinearMap is quite a bit faster, and is fully owned/sendable without
requiring copies. The older std::map also doesn't use explicit self and
relies on mutable fields.
Changes:
- Refactor move mode computation
- Removes move mode arguments, unary move, capture clauses
(though they still parse for backwards compatibility)
- Simplify how moves are handled in trans
- Fix a number of illegal copies that cropped up
- Workaround for bug involving def-ids in params
(see details below)
Future work (I'll open bugs for these...):
- Improve error messages for moves that are due
to bindings
- Add support for moving owned content like a.b.c
to borrow check, test in trans (but I think it'll
"just work")
- Proper fix for def-ids in params
Def ids in params:
Move captures into a map instead of recomputing.
This is a workaround for a larger bug having to do with the def-ids associated
with ty_params, which are not always properly preserved when inlining. I am
not sure of my preferred fix for the larger bug yet. This current fix removes
the only code in trans that I know of which relies on ty_param def-ids, but
feels fragile.
"Dual impls" are impls that are both type implementations and trait
implementations. They can lead to ambiguity and so this patch removes them
from the language.
This also enforces coherence rules. Without this patch, records can implement
traits not defined in the current crate. This patch fixes this, and updates
all of rustc to adhere to the new enforcement. Most of this patch is fixing
rustc to obey the coherence rules, which involves converting a bunch of records
to structs.
needed.
Regarding soundness: there was a subtle bug in how it was done before; see the
compile-fail test for an example.
Regarding reborrowing: reborrowing allows mut and const
slices/borrowed-pointers to be used with pure fns that expect immutable data.
r=brson
