Add warning against unexpected --cfg with --check-cfg
This PR adds a warning when an unexpected `--cfg` is specified but not in the specified list of `--check-cfg`.
This is the follow-up PR I mentioned in https://github.com/rust-lang/rust/pull/99519.
r? `@petrochenkov`
Cleanup css theme
Follow-up of https://github.com/rust-lang/rust/pull/100494.
The change for the border color of the search input in the dark mode was actually a weird case: the search input border was unique, it didn't share the same variable with other items with borders. This weird case being unique to the dark theme, I removed it, hence the modification in the GUI test.
Live demo is [here](https://rustdoc.crud.net/imperio/cleanup-css-theme/std/index.html).
cc `@jsha`
r? `@notriddle`
[drop tracking] Use parent expression for scope, not parent node
Previously we were just using the parent node as the scope for a temporary value, but it turns out this is too narrow. For example, in an expression like
Foo {
b: &42,
a: async { 0 }.await,
}
the scope for the &42 was set to the ExprField node for `b: &42`, when we actually want to use the Foo struct expression.
We fix this by recursively searching through parent nodes until we find a Node::Expr. It may be that we don't find one, and if so that's okay, we will just fall back on the enclosing temporary scope which is always sufficient.
Helps with #97331
r? ``@jyn514``
Revert "Remove deferred sized checks"
cc: https://github.com/rust-lang/rust/pull/100652#issuecomment-1225798572
I'm okay with reverting this for now, and I will look into the diagnostic regressions.
This reverts commit 33212bf7f5.
r? `@pnkfelix`
----
EDIT: This _also_ fixes#101066, a regression in method selection logic/coercion(?) due to the early registering of a `Sized` bound.
Support `#[unix_sigpipe = "inherit|sig_dfl"]` on `fn main()` to prevent ignoring `SIGPIPE`
When enabled, programs don't have to explicitly handle `ErrorKind::BrokenPipe` any longer. Currently, the program
```rust
fn main() { loop { println!("hello world"); } }
```
will print an error if used with a short-lived pipe, e.g.
% ./main | head -n 1
hello world
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:1016:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
by enabling `#[unix_sigpipe = "sig_dfl"]` like this
```rust
#![feature(unix_sigpipe)]
#[unix_sigpipe = "sig_dfl"]
fn main() { loop { println!("hello world"); } }
```
there is no error, because `SIGPIPE` will not be ignored and thus the program will be killed appropriately:
% ./main | head -n 1
hello world
The current libstd behaviour of ignoring `SIGPIPE` before `fn main()` can be explicitly requested by using `#[unix_sigpipe = "sig_ign"]`.
With `#[unix_sigpipe = "inherit"]`, no change at all is made to `SIGPIPE`, which typically means the behaviour will be the same as `#[unix_sigpipe = "sig_dfl"]`.
See https://github.com/rust-lang/rust/issues/62569 and referenced issues for discussions regarding the `SIGPIPE` problem itself
See the [this](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem) Zulip topic for more discussions, including about this PR.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
Try normalizing types without RevealAll in ParamEnv in MIR validation
Before, the MIR validator used RevealAll in its ParamEnv for type
checking. This could cause false negatives in some cases due to
RevealAll ParamEnvs not always use all predicates as expected here.
Since some MIR passes like inlining use RevealAll as well, keep using
it in the MIR validator too, but when it fails usign RevealAll, also
try the check without it, to stop false negatives.
Fixes#99866
cc ````````@compiler-errors```````` who nicely helped me on zulip
Simplify MIR opt tests
This commit removes many cases of MIR opt tests emitting `.diff`s for more than one pass. These tests cannot be `unit-test`s, and so they are easy to break, and they also provide little value due to having excessively strong opinions over *how* a piece of code should be optimized.
Where reasonable, we instead add separate test files that only emit the `PreCodegen.after` MIR for code where we want to track what the end to end effect of the optimization pipeline on the example code is.
r? `````@wesleywiser`````
Uplift the `let_underscore` lints from clippy into rustc.
This PR resolves#97241.
This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior)
In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach?
Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?)
On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet.
r? `@estebank`
This commit removes many cases of MIR opt tests emitting `.diff`s for more than one pass. These
tests cannot be `unit-test`s, and so they are easy to break, and they also provide little value due
to having excessively strong opinions over *how* a piece of code should be optimized.
Where reasonable, we instead add separate test files that only emit the `PreCodegen.after` MIR for
code where we want to track what the result of the net result of the optimization pipeline's output
is.
Fix doc_auto_cfg for impl blocks in different modules with different `cfg`
Fixes#101129.
Just like reexports, impl blocks don't necessarily share the same "space" as the item they implement so we need to merge attributes from its parents as well.
r? `@notriddle`
Add `special_module_name` lint
Declaring `lib` as a module is one of the most common beginner mistakes when trying to setup a binary and library target in the same crate. `special_module_name` lints against it, as well as `mod main;`
```
warning: found module declaration for main.rs
--> $DIR/special_module_name.rs:4:1
|
LL | mod main;
| ^^^^^^^^^
|
= note: a binary crate cannot be used as library
warning: found module declaration for lib.rs
--> $DIR/special_module_name.rs:1:1
|
LL | mod lib;
| ^^^^^^^^
|
= note: `#[warn(special_module_name)]` on by default
= note: lib.rs is the root of this crate's library target
= help: to refer to it from other targets, use the library's name as the path
```
Note that the help message is not the best in that it doesn't provide an example of an import path (`the_actual_crate_name::`), and doesn't check whether the current file is part of a library/binary target to provide more specific error messages. I'm not sure where this lint would have to be run to access that information.
This reimplements ac638c1, which had to be reverted in the previous
commit because it contains a rebase accident that itself reverted
significant unrelated changes to SessionSubdiagnostic.
This reverts parts of commit ac638c1f5f.
During rebase, this commit accidentally reverted unrelated changes to
the subdiagnostic derive (those allowing multipart_suggestions to be
derived). This commit reverts all changes to the subdiagnostic code made
in ac638c1f5f, the next commit will reintroduce the actually intended
changes.
ci: Upgrade non-dist Linux testers from ubuntu:16.04 to 22.04
The main goal of updating to 22.04 is to get away from `llvm.allow-old-toolchain`.
A side benefit is that they can also use the system `cmake` instead of building one.
Fix a bunch of typo
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
lint: avoid linting diag functions with diag lints
Functions annotated with `#[rustc_lint_diagnostics]` are used by the diagnostic migration lints to know when to lint, but functions that are annotated with this attribute shouldn't themselves be linted.
cc #100717https://github.com/rust-lang/rust/pull/101041#discussion_r959303706
Fix uintended diagnostic caused by `drain(..)`
Calling `drain(..)` makes later `suggestable_variants.is_empty()` always true, which makes the diagnostics unintended.
migrate rustc_query_system to use SessionDiagnostic
issues:
* variable list is not supported in fluent
* ~~cannot have two sub diagnostic with the same tag (eg. 2 .note or 2 .help)~~
allow multiple tag with SessionSubdiagnostic derive
Functions annotated with `#[rustc_lint_diagnostics]` are used by the
diagnostic migration lints to know when to lint, but functions that are
annotated with this attribute shouldn't themselves be linted.
Signed-off-by: David Wood <david.wood@huawei.com>
Migrate rustc_monomorphize to use SessionDiagnostic
### Description
- Migrates diagnostics in `rustc_monomorphize` to use `SessionDiagnostic`
- Adds an `impl IntoDiagnosticArg for PathBuf`
### TODO / Help!
- [x] I'm having trouble figuring out how to apply an optional note. 😕 Help!?
- Resolved. It was bad docs. Fixed in https://github.com/rust-lang/rustc-dev-guide/pull/1437/files
- [x] `errors:RecursionLimit` should be `#[fatal ...]`, but that doesn't exist so it's `#[error ...]` at the moment.
- Maybe I can switch after this is merged in? --> https://github.com/rust-lang/rust/pull/100694
- Or maybe I need to manually implement `SessionDiagnostic` instead of deriving it?
- [x] How does one go about converting an error inside of [a call to struct_span_lint_hir](8064a49508/compiler/rustc_monomorphize/src/collector.rs (L917-L927))?
- [x] ~What placeholder do you use in the fluent template to refer to the value in a vector? It seems like [this code](0b79f758c9/compiler/rustc_macros/src/diagnostics/diagnostic_builder.rs (L83-L114)) ought to have the answer (or something near it)...but I can't figure it out.~ You can't. Punted.
This PR will fix some typos detected by [typos].
I only picked the ones I was sure were spelling errors to fix, mostly in
the comments.
[typos]: https://github.com/crate-ci/typos
