rustc_typeck: gate AnonConst's generics on feature(const_generics).
This PR employs the fix for #43408 when `#![feature(const_generics)]` is enabled, making the feature-gate the opt-in for all the possible breakage this may incur.
For example, if this PR lands, this will cause a cycle error (due to #60471):
```rust
#![feature(const_generics)]
fn foo<T: Into<[u8; 4]>>() {}
```
And so will anything with type-level const expressions, in its bounds.
Surprisingly, `impl`s don't seem to be affected (if they were, even libcore wouldn't compile).
One thing I'm worried about is not knowing how much unstable code out there, using const-generics, will be broken. But types like `Foo<{N+1}>` never really worked, and do after this PR, just not in bounds - so ironically, it's type-level const expressions that don't depend on generics, which will break (in bounds).
Also, if we do this, we'll have effectively blocked stabilization of const generics on #60471.
r? @oli-obk cc @varkor @yodaldevoid @nikomatsakis
Use LLVMAddAnalysisPasses instead of Rust's wrapper
LLVM exposes a C API `LLVMAddAnalysisPasses` and hence Rust's own wrapper `LLVMRustAddAnalysisPasses` is not needed anymore.
impl TrustedLen for vec::Drain
The iterator methods just forward to `slice::Iter`, which is `TrustedLen`.
This can probably be applied to other `Drain` structs as well.
Atomic as_mut_ptr
I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type).
It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477
Transmuting the pointer directly:
```rust
let atomic = AtomicI32::new(1);
let ptr = &atomic as *const AtomicI32 as *mut i32;
unsafe {
ffi(ptr);
}
```
A dance with `UnsafeCell`:
```rust
let atomic = AtomicI32::new(1);
unsafe {
let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get();
ffi(ptr);
}
```
Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library?
An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race."
The standard library could make use this method in a few places in the WASM module.
cc @RalfJung as you answered my original question.
Initial implementation of or-pattern usefulness checking
The title says it all.
I'd like to request a perf run on that, hopefully this doesn't kill performance too much.
cc https://github.com/rust-lang/rust/issues/54883
These three lines are from c82da7a54b in
2015.
They cause problems when applying rustfmt to the codebase, because
reordering wildcard imports can trigger new unused import warnings.
As a minimized example, the following program compiles successfully:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use std::prelude::v1::*;
use super::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
but putting it through rustfmt produces a program that fails to compile:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use super::*;
use std::prelude::v1::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
The error is:
error: unused import: `std::prelude::v1::*`
--> src/main.rs:8:9
|
8 | use std::prelude::v1::*;
| ^^^^^^^^^^^^^^^^^^^
Allow any identifier as format arg name
Previously:
```console
error: invalid format string: invalid argument name `_x`
--> src/main.rs:2:16
|
2 | println!("{_x}", _x=0);
| ^^ invalid argument name in format string
|
= note: argument names cannot start with an underscore
```
Not supporting identifiers starting with underscore appears to have been an arbitrary limitation from 2013 in code that was most likely never reviewed: https://github.com/rust-lang/rust/pull/8245/files#diff-0347868ef389c805e97636623e4a4ea6R277
The error message was dutifully improved in #50610 but is there any reason that leading underscore would be a special case?
This commit updates the format_args parser to accept identifiers with leading underscores.
Format libstd with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts, and are not part of libstd/os (#66818) or libstd/sys (#66819). The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
$ find src/libstd -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of most of the rest of libstd.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
Format libstd/sys with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
$ find src/libstd/sys -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/sys outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
Format libstd/os with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/os *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
$ find src/libstd/os -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/os outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd *that are not involved in any currently open PR* to
minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libstd.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/sys *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd/sys -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/sys outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/os *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd/os -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/os outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
