| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Take commandline arguments into account for incr. comp.
Implements the conservative strategy described in https://github.com/rust-lang/rust/issues/33727.
From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the `[TRACKED]` or the `[UNTRACKED]` marker next to the field. The `Options`, `CodegenOptions`, and `DebuggingOptions` definitions in `session::config` show plenty of examples.
The PR removes some cruft from `session::config::Options`, mostly unnecessary copies of flags also present in `DebuggingOptions` or `CodeGenOptions` in the same struct.
One notable removal is the `cfg` field that contained the values passed via `--cfg` commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in `hir::Crate::config` and it's pretty likely that reading the cfgs from `Options` would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the `Options` struct because of how the test framework works, leaving us with a piece of untracked but vital data.
It is now recommended (just as before) to access the crate config via the `krate()` method in the HIR map.
Because the `cfg` field is not present in the `Options` struct any more, some methods in the `CompilerCalls` trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.
|
|
|
|
Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
|
|
When we emit E0453 (lint level attribute overruled by outer `forbid`
lint level), it could be helpful to note where the `forbid` level was
set, for the convenience of users who, e.g., believe that the correct
fix is to weaken the `forbid` to `deny`.
|
|
intravisit: Fold functionality of IdVisitor into the regular Visitor.
|
|
|
|
|
|
|
|
|
|
|
|
Also enhances the error message a bit, fixes #30505 on the way, and adds
a test (which was missing).
Closes #34018
|
|
This is a spiritual succesor to #34268/8531d581, in which we replaced a
number of matches of None to the unit value with `if let` conditionals
where it was judged that this made for clearer/simpler code (as would be
recommended by Manishearth/rust-clippy's `single_match` lint). The same
rationale applies to matches of None to the empty block.
|
|
Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`.
|
|
Refactor away `ast::Decl`, refactor `ast::Stmt`, and rename `ast::ExprKind::Again` to `ast::ExprKind::Continue`.
|
|
Miscellaneous low priority cleanup in `libsyntax`.
|
|
|
|
|
|
|
|
|
|
lifetime/label names
|
|
|
|
This is a step towards fixing #32330. The full fix would be a breaking
change, so we begin by issuing warnings for scenarios that will break.
|
|
|
|
|
|
|
|
this commit should be reverted after a release cycle
|
|
It does not help you to understand the error, just explains why you are
seeing it, so it is clearly secondary.
|
|
The extra filename and line was mainly there to keep the indentation
relative to the main snippet; now that this doesn't include
filename/line-number as a prefix, it is distracted.
|
|
|
|
change constant patterns to have a warning cycle
This was the original intention :(
r? @eddyb
|
|
r? @nikomatsakis
Conflicts:
src/librustc_save_analysis/lib.rs
src/libsyntax/ast_util.rs
|
|
This was the original intention :(
|
|
|
|
|
|
|
|
|
|
Fix issue: Global paths in `use` directives can begin with `super` or `self` #32225
This PR fixes #32225 by warning on `use ::super::...` and `use ::self::...` on `resolve`.
Current changes is the most minimal and ad-hoc.
|
|
Issue: #32225
|
|
|
|
|
|
|
|
|
|
|
|
This is a [breaking-change]: according to RFC #1445, constants used as
patterns must be of a type that *derives* `Eq`. If you encounter a
problem, you are most likely using a constant in an expression where the
type of the constant is some struct that does not currently implement
`Eq`. Something like the following:
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
The easiest and most future compatible fix is to annotate the type in
question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is
not enough, it must be *derived*):
```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;
match foo {
SOME_CONST => ...
}
```
Another good option is to rewrite the match arm to use an `if`
condition (this is also particularly good for floating point types,
which implement `PartialEq` but not `Eq`):
```rust
match foo {
c if c == SOME_CONST => ...
}
```
Finally, a third alternative is to tag the type with
`#[structural_match]`; but this is not recommended, as the attribute is
never expected to be stabilized. Please see RFC #1445 for more details.
|
|
This adds the `renamed_and_removed_lints` warning, defaulting
to the warning level.
Fixes #31141
|
|
|
|
|
|
Show clearer error message when #![deny(warnings)] escalates a warning
Addresses #30730
|
|
|
