Update Clippy dependencies
Clippy has two outdated dependencies, where one indirect dependency has been flagged by rustsec for dropping a lifetime. See [RUSTSEC-2020-0146](https://rustsec.org/advisories/RUSTSEC-2020-0146). This PR updates these dependencies.
With previous dependency updates, it was tried to prevent duplicates in the `Cargo.lock` file of rust-lang/rust. I've tried to keep this in mind with this update.
* Dependency `semver`
* Used in `src/tools/cargo/Cargo.toml` as version `1.0.3`
* Used in `src/tools/rust-analyzer/crates/project_model/Cargo.toml` as version `1`
* Updated in Clippy from `0.11` to `1.0` (Clippy usually defines the major and minor patch version). The `Cargo.lock` file lists `1.0.3` which is one patch version behind the most recent one but prevents a duplicate with cargo's pinned version.
* Dependency `cargo_metadata`
* Used in several tools as `0.14`
* Used in `src/tools/tidy` and `src/tools/rls` as `0.12`
* Updated in Clippy from `0.12` to `0.14`
All updates to the `Cargo.lock` have been done automatically by `x.py`.
There are still some tools with these outdated dependencies. Clippy didn't require any changes, and it would be likely that the others could also be updated without any problem. Let me know if I should try to update them as well 🙃.
Keep up the good work, whoever is reading this 🦀
---
For Clippy:
changelog: none
Clarify what to do with accepted feature gates
The documentation only referenced `removed.rs`, but feature gates for
accepted features move to `accepted.rs`.
Document clippy on nightly-rustc
Adding Clippy's docs to nightly-rustc, based on commit 01cf0bde. This PR only adds `clippy_utils` to the documentation. I've decided to only document one crate for now, as `clippy_lints` etc. contain very specific and undocumented functions which aren't really reusable. I'm guessing that they would mostly clutter up the search results with little benefit.
`./x.py --stage 1 doc src/tools/clippy` if working fine now after the help that ```````@jyn514``````` and ```````@ehuss``````` have provided. A big THANK YOU to them!
Make printed message match the code comment
I think this code is getting L0, not L1 cache size, if I'm reading the Intel manual right. (I might not be.) Either way, the code comment and the printed message should match, whichever way is right. :)
Use .cargo/config.toml instead of .cargo/config
`.cargo/config.toml` is the preferred form for the local configuration file. This is emphasized in _The Cargo Book_ with the following note:
> Note: Cargo also reads config files without the `.toml` extension, such as `.cargo/config`. Support for the `.toml` extension was added in version 1.39 and is the preferred form.
Moreover, this helps with toml-aware text editors as they will recognize the file extension.
changelog: none
`.cargo/config.toml` is the preferred form for the local configuration
file. This is emphasized in _The Cargo Book_ with the following note:
> Note: Cargo also reads config files without the `.toml` extension, such
> as `.cargo/config`. Support for the `.toml` extension was added in version
> 1.39 and is the preferred form.
Moreover, this helps with toml-aware text editors as they will recognize
the file extension.
Windows thread-local keyless drop
`#[thread_local]` allows us to maintain a per-thread list of destructors. This also avoids the need to synchronize global data (which is particularly tricky within the TLS callback function).
r? `@alexcrichton`
Move non_ascii_literal to restriction
It feels like the more apt category, since cases where you'd want it enabled would be pretty specific
changelog: Move [`non_ascii_literal`] to `restriction`
Prevent clippy::needless_lifetimes false positive in async function definition
Scan `OpaqueDef` bounds for lifetimes as well. Those `OpaqueDef` instances are generated while desugaring an `async` function definition.
This fixes#7893
changelog: Prevent [`clippy::needless_lifetimes`] false positive in `async` function definition
Fix manual_assert and match_wild_err_arm for `#![no_std]` and Rust 2021
Rust 2015 `std::panic!` has a wrapping block while `core::panic!` and Rust 2021 `std::panic!` does not. See rust-lang/rust#88919 for details.
Note that the test won't pass until clippy changes in rust-lang/rust#88860 is synced.
---
changelog: Fix [`manual_assert`] and [`match_wild_err_arm`] for `#![no_std]` and Rust 2021.
Fixes#7723
Unseparated literal suffix
Closes#7658
Since `literal_suffix` style is opinionated, we should disable by default and only enforce if it's stated as so.
changelog: [`unseparated_literal_suffix`] is renamed to `literal_suffix`, adds a new configuration `literal-suffix-style` to enforce a certain style writing literal_suffix. Possible values for `literal-suffix-style`: `"separated"`, `"unseparated"`
avoid linting `possible_truncation` on bit-reducing operations
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: avoid linting `possible_truncation` on bit-reducing operations
Add JoinHandle::is_running.
This adds:
```rust
impl<T> JoinHandle<T> {
/// Checks if the the associated thread is still running its main function.
///
/// This might return `false` for a brief moment after the thread's main
/// function has returned, but before the thread itself has stopped running.
pub fn is_running(&self) -> bool;
}
```
The usual way to check if a background thread is still running is to set some atomic flag at the end of its main function. We already do that, in the form of dropping an Arc which will reduce the reference counter. So we might as well expose that information.
This is useful in applications with a main loop (e.g. a game, gui, control system, ..) where you spawn some background task, and check every frame/iteration whether the background task is finished to .join() it in that frame/iteration while keeping the program responsive.
Update cargo
3 commits in 6c1bc24b8b49d4bc965f67d7037906dc199c72b7..94ca096afbf25f670e76e07dca754fcfe27134be
2021-10-24 17:51:41 +0000 to 2021-10-29 14:45:06 +0000
- Chore: prefer `HashMap::from` rather than collecting `Vec` of tuples (rust-lang/cargo#10018)
- Change --scrape-examples flag to -Z rustdoc-scrape-examples (rust-lang/cargo#10017)
- Scrape code examples from examples/ directory for Rustdoc (rust-lang/cargo#9525)
CI: Use ubuntu image to download openssl, curl sources, cacert.pem for x86 dist builds
The dist-x86_64 and dist-i686 docker builds are failing again (see [try build](https://github.com/rust-lang-ci/rust/runs/4060836540?check_suite_focus=true)) because python.org renewed its certificate with a CA cert that is too new for debian:6.
In order to solve this once and for all this PR moves the curl and openssl downloads to a new ubuntu:20.04 "stage-0" docker build and copies the downloaded tarballs over to build them in the "stage-1" debian:6 context. It also downloads the cacert.pem file from the curl website and uses it by pointing the `CURL_CA_BUNDLE` environment variable to it.
Collect `panic/panic_bounds_check` during monomorphization
This would prevent link time errors if these functions are `#[inline]` (e.g. when `panic_immediate_abort` is used).
Fix#90405Fixrust-lang/cargo#10019
`@rustbot` label: T-compiler A-codegen
After updating the minimum required LLVM version to 12 we can use
apple-a14 as that is closer in features to the Apple M1 than the A12.
Once the minimum required LLVM version is updated to 13 we can use
apple-m1.
update most tests to 2021 edition
Some tests would no longer work at all, so I added `edition:2015` or `edition:2018` to them.
Notably 2021 panics are not yet detected correctly. Once ready, this closes#7842.
---
changelog: none
`unseparated_literal_suffix`
This commit adds a configuration `literal-suffix-style` to enforce a
specific style for unseparated_literal_suffix. The configuration accepts
two values:
- "separated"
enforce all literals to be written separately (e.g. `123_i32`)
- "unseparated"
enforce all literals to be written as unseparated (e.g. `123i32`)
Not specifying a value means that there is no preference on style and
any style should not be warned.
