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
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
Miri: do not consider memory allocated by caller_location leaked
Fixes https://github.com/rust-lang/miri/issues/1071
r? @oli-obk
I am not sure if this is the best approach, but it certainly is the easiest.
Clarify `{f32,f64}::EPSILON` docs
The doc for `EPSILON` says:
> This is the difference between `1.0` and the next **largest** representable number.
Which is a bit unclear.
[Wikipedia](https://en.wikipedia.org/wiki/Machine_epsilon) says
> Machine epsilon is defined as the difference between 1 and the next **larger** floating point number
So this PR update the docs to match the Wikipedia version.
The original PR also has this in a [comment](https://github.com/rust-lang/rust/pull/50919#discussion_r192600209).
Record temporary static references in generator witnesses
Closes#66695
* Record the pointer to static's type in MIR.
* Normalize the static's type (so that constants can be compared correctly).
Handle GlobalCtxt directly from librustc_interface query system
This PR constructs the `GlobalCtxt` as a member of the `Queries` in librustc_interface.
This simplifies the code to construct it, at the expense of added complexity in the query control flow.
This allows to handle the arenas directly from librustc_interface.
Based on #66707
r? @Zoxc
Panic machinery comments and tweaks
This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.
r? @Dylan-DPC @SimonSapin
Allow customising ty::TraitRef's printing behavior
This pr allows to explicitly choose which representation of `TraitRef` (`<T as Trait<U>>` or `Trait<U>`) you want to print. `Debug` and `Display` representations of `TraitRef` now match.
Closes#59188.
Draw vertical lines correctly in compiler error messages
... with multiline annotations correctly when non-1space unicode characters are to the left
For this we use the correct calculation of the 'left' identation
closes#66552
Async fn resume after completion
#65419 -- Attempting to run an async fn after completion mentions generators
Not yet ready for review - work in progress
Just need to run the tests on a proper build server
rustc_metadata: Privatize more things and a couple of other refactorings
This PR continues https://github.com/rust-lang/rust/pull/66496 and hits the point of diminishing returns.
All fields of `CrateRoot` and `CrateMetadata` are privatized.
For read-only fields this certainly makes sense, but for a few fields updateable from outside of `rmeta.rs` (mostly `creader.rs`) it was done mostly for consistency, I can make them `pub(crate)` again if requested.
`cstore.rs` (which became small after #66496) was merged into `creader.rs`.
A few things noticed while making the privacy changes were addressed in the remaining refactoring commits.
Fixes https://github.com/rust-lang/rust/issues/66550
r? @eddyb @Mark-Simulacrum
Apply proper commit from PR #63934
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
Fallback to .init_array when no arguments are available on glibc Linux
Linux is one of the only platforms where `std::env::args` doesn't work in a cdylib.
Previously:
error: invalid format string: invalid argument name `_x`
--> src/main.rs:2:16
|
2 | println!("{_x}", a=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.
While working on PR #63934, I accidentally reverted to an older version
of the PR while working on a rebase. The PR was then merged, not with
the later, approved changes, but with earlier, unapproved changes.
This PR applies the changes that were *suppoesd* to be mereged in
PR #63934. All of the proper tests appear to have been merged
in PR #63934, so this PR adds no new tests
Fixes#66580
Namely, `update_extern_crate`.
Also, stop tracking visited crates in `update_extern_crate`, the rank check does the same thing (prevents visiting dependencies if the rank didn't change), but more precisely.
