Matthias Krüger [Tue, 11 Oct 2022 16:59:45 +0000 (18:59 +0200)]
Rollup merge of #100387 - cjgillot:hygiene-trait-impl, r=petrochenkov
Check uniqueness of impl items by trait item when applicable.
When checking uniqueness of item names in impl blocks, we currently use the same definition of hygiene as for toplevel items. This means that a plain item and one generated by a macro 2.0 do not collide.
This hygiene rule does not match with how impl items resolve to associated trait items. As a consequence, we misdiagnose the trait impls.
This PR proposes to consider that trait impl items are uses of the corresponding trait items during resolution, instead of checking for duplicates later. An error is emitted when a trait impl item is used twice.
There should be no stable breakage, since macros 2.0 are still unstable.
This commit does have to change `h1.fqn a` to just be `h1 a`, so that the
header link color selector is less specific than the typed link at the end.
Since #89506 made docblocks start at `h2`, the main page link header should
be the only h1 in the page now.
Yuki Okushi [Tue, 11 Oct 2022 09:37:55 +0000 (18:37 +0900)]
Rollup merge of #102859 - cjgillot:collect-lifetimes, r=oli-obk
Move lifetime resolution module to rustc_hir_analysis.
Now that lifetime resolution has been removed from it, this file has nothing to do in `rustc_resolve`. It's purpose is to compute Debruijn indices for lifetimes, so let's put it in type collection.
Yuki Okushi [Tue, 11 Oct 2022 09:37:54 +0000 (18:37 +0900)]
Rollup merge of #102589 - RalfJung:scoped-threads-dangling, r=m-ou-se
scoped threads: pass closure through MaybeUninit to avoid invalid dangling references
The `main` function defined here looks roughly like this, if it were written as a more explicit stand-alone function:
```rust
// Not showing all the `'lifetime` tracking, the point is that
// this closure might live shorter than `thread`.
fn thread(control: ..., closure: impl FnOnce() + 'lifetime) {
closure();
control.signal_done();
// A lot of time can pass here.
}
```
Note that `thread` continues to run even after `signal_done`! Now consider what happens if the `closure` captures a reference of lifetime `'lifetime`:
- The type of `closure` is a struct (the implicit unnameable closure type) with a `&'lifetime mut T` field. References passed to a function are marked with `dereferenceable`, which is LLVM speak for *this reference will remain live for the entire duration of this function*.
- The closure runs, `signal_done` runs. Then -- potentially -- this thread gets scheduled away and the main thread runs, seeing the signal and returning to the user. Now `'lifetime` ends and the memory the reference points to might be deallocated.
- Now we have UB! The reference that as passed to `thread` with the promise of remaining live for the entire duration of the function, actually got deallocated while the function still runs. Oops.
Long-term I think we should be able to use `ManuallyDrop` to fix this without `unsafe`, or maybe a new `MaybeDangling` type. I am working on an RFC for that. But in the mean time it'd be nice to fix this so that Miri with `-Zmiri-retag-fields` (which is needed for "full enforcement" of all the LLVM flags we generate) stops erroring on scoped threads.
bors [Tue, 11 Oct 2022 08:09:41 +0000 (08:09 +0000)]
Auto merge of #102755 - pcc:data-local-tmp, r=Mark-Simulacrum
tools/remote-test-{server,client}: Use /data/local/tmp on Android
The /data/tmp directory does not exist, at least not on recent versions of Android, which currently leads to test failures on that platform. I checked a virtual device running AOSP master and a Nexus 5 running Android Marshmallow and on both devices the /data/tmp directory does not exist and /data/local/tmp does, so let's switch to /data/local/tmp.
bors [Tue, 11 Oct 2022 04:27:13 +0000 (04:27 +0000)]
Auto merge of #102724 - pcc:scs-fix-test, r=Mark-Simulacrum
Fix the sanitizer_scs_attr_check.rs test
The test is failing when targeting aarch64 Android. The intent appears to have been to look for a function attributes comment (or the absence of one) on the line preceding the function declaration. But this isn't quite possible with FileCheck and the test as written was looking for a line with `no_scs` after a line with `scs`, which doesn't appear in the output. Instead, match on the function attributes comment on the line following the demangled function name comment.
Matthias Krüger [Mon, 10 Oct 2022 18:47:34 +0000 (20:47 +0200)]
Rollup merge of #102876 - SparrowLii:import-candidate, r=fee1-dead
suggest candidates for unresolved import
Currently we prompt suggestion of candidates(help notes of `use xxx::yyy`) for names which cannot be resolved, but we don't do that for import statements themselves that couldn't be resolved. It seems reasonable to add candidate help information for these statements as well.
Fixes #102711
Matthias Krüger [Mon, 10 Oct 2022 18:47:33 +0000 (20:47 +0200)]
Rollup merge of #102871 - notriddle:notriddle/trait-impl-anchor, r=GuillaumeGomez
rustdoc: clean up overly complex `.trait-impl` CSS selectors
When added in 45964368f4a2e31c94e9bcf1cef933c087d21544, these multi-class selectors were present in the initial commit, but no reason was given why the shorter selector wouldn't work.
To check-in `rustc-src` for hermetic builds in environments with
restrictive `.gitignore` policies, one has to remove these
`tests/.gitignore` and patch the respective
`.cargo-checksum.json`.`syn` >1.0.101 includes dtolnay/syn@3c49303bed7a,
which removes its `tests/.gitignore`. Now the `syn` crates.io package
has no `.gitignore`.
[`rustc-src`'s `vendor`][] is produced from the root `Cargo.toml`,
`src/tools/rust-analyzer/Cargo.toml`,
`compiler/rustc_codegen_cranelift/Cargo.toml`, and
`src/bootstrap/Cargo.toml`. `rustc_codegen_cranelift` does not use
`syn`.
Andrew Brown [Thu, 29 Sep 2022 18:17:15 +0000 (11:17 -0700)]
Implement `env_lock` with `RwLock`
Copying the approach of the Unix target, this change uses the standard
`RwLock` to protect against concurrent access of libc's environment.
This locking is only enabled when WebAssembly's `atomics` feature is
also enabled.
Andrew Brown [Tue, 27 Sep 2022 18:50:47 +0000 (11:50 -0700)]
Allow compiling the `wasm32-wasi` std library with atomics
The issue #102157 demonstrates how currently the `-Z build-std` option
will fail when re-compiling the standard library with `RUSTFLAGS` like
`RUSTFLAGS="-C target-feature=+atomics,+bulk-memory -C
link-args=--shared-memory"`. This change attempts to resolve those build
issues by depending on the the WebAssembly `futex` module and providing
an implementation for `env_lock`. Fixes #102157.
David Wood [Mon, 3 Oct 2022 15:10:34 +0000 (16:10 +0100)]
macros: simplify field ordering in diag derive
Following the approach taken in earlier commits to separate formatting
initialization from use in the subdiagnostic derive, simplify the
diagnostic derive by removing the field-ordering logic that previously
solved this problem.
David Wood [Mon, 3 Oct 2022 13:28:02 +0000 (14:28 +0100)]
macros: separate suggestion fmt'ing and emission
Diagnostic derives have previously had to take special care when
ordering the generated code so that fields were not used after a move.
This is unlikely for most fields because a field is either annotated
with a subdiagnostic attribute and is thus likely a `Span` and copiable,
or is a argument, in which case it is only used once by `set_arg`
anyway.
However, format strings for code in suggestions can result in fields
being used after being moved if not ordered carefully. As a result, the
derive currently puts `set_arg` calls last (just before emission), such
as:
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
diag.emit();
```
For eager translation, this doesn't work, as the message being
translated eagerly can assume that all arguments are available - so
arguments _must_ be set first.
Format strings for suggestion code are now separated into two parts - an
initialization line that performs the formatting into a variable, and a
usage in the subdiagnostic addition.
By separating these parts, the initialization can happen before
arguments are set, preserving the desired order so that code compiles,
while still enabling arguments to be set before subdiagnostics are
added.
```rust
let diag = { /* create diagnostic */ };
let __code_0 = format!("{}", __binding_0);
/* + other formatting */
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
David Wood [Mon, 3 Oct 2022 13:14:51 +0000 (14:14 +0100)]
errors: `DiagnosticMessage::Eager`
Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the
emitter during emission). Also adds `eager_subdiagnostic` function which
is intended to be invoked by the diagnostic derive for subdiagnostic
fields which are marked as needing eager translation.
David Wood [Mon, 3 Oct 2022 13:09:05 +0000 (14:09 +0100)]
errors: `AddToDiagnostic::add_to_diagnostic_with`
`AddToDiagnostic::add_to_diagnostic_with` is similar to the previous
`AddToDiagnostic::add_to_diagnostic` but takes a function that can be
used by the caller to modify diagnostic messages originating from the
subdiagnostic (such as performing translation eagerly).
`add_to_diagnostic` now just calls `add_to_diagnostic_with` with an
empty closure.
David Wood [Mon, 3 Oct 2022 13:02:49 +0000 (14:02 +0100)]
errors: use `HashMap` to store diagnostic args
Eager translation will enable subdiagnostics to be translated multiple
times with different arguments - this requires the ability to replace
the value of one argument with a new value, which is better suited to a
`HashMap` than the previous storage, a `Vec`.
bors [Mon, 10 Oct 2022 12:09:21 +0000 (12:09 +0000)]
Auto merge of #96711 - emilio:inline-slice-clone, r=nikic
slice: #[inline] a couple iterator methods.
The one I care about and actually saw in the wild not getting inlined is
clone(). We ended up doing a whole function call for something that just
copies two pointers.
I ended up marking as_slice / as_ref as well because make_slice is
inline(always) itself, and is also the kind of think that can kill
performance in hot loops if you expect it to get inlined. But happy to
undo those.
bors [Mon, 10 Oct 2022 09:12:06 +0000 (09:12 +0000)]
Auto merge of #102875 - Dylan-DPC:rollup-zwcq8h9, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #99696 (Uplift `clippy::for_loops_over_fallibles` lint into rustc)
- #102055 (Move some tests to more reasonable directories)
- #102786 (Remove tuple candidate, nothing special about it)
- #102794 (Make tests capture the error printed by a Result return)
- #102853 (Skip chained OpaqueCast when building captures.)
- #102868 (Rename `AssocItemKind::TyAlias` to `AssocItemKind::Type`)
Dylan DPC [Mon, 10 Oct 2022 08:13:41 +0000 (13:43 +0530)]
Rollup merge of #102794 - dtolnay:termination, r=thomcc
Make tests capture the error printed by a Result return
An error returned by tests previously would get written directly to stderr, instead of to the capture buffer set up by the test harness. This PR makes it write to the capture buffer so that it can be integrated as part of the test output by build tools such as `buck test`, since being able to read the error message returned by a test is pretty critical to debugging why the test failed.
Dylan DPC [Mon, 10 Oct 2022 08:13:40 +0000 (13:43 +0530)]
Rollup merge of #99696 - WaffleLapkin:uplift, r=fee1-dead
Uplift `clippy::for_loops_over_fallibles` lint into rustc
This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this:
```rust
for _ in Some(1) {}
for _ in Ok::<_, ()>(1) {}
```
i.e. directly iterating over `Option` and `Result` using `for` loop.
There are a number of suggestions that this PR adds (on top of what clippy suggested):
1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later)
```rust
for _ in iter.next() {}
// turns into
for _ in iter.by_ref() {}
```
2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels
```rust
for _ in rx.recv() {}
// turns into
while let Some(_) = rx.recv() {}
```
3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?`
```rust
for _ in f() {}
// turns into
for _ in f()? {}
```
4. To preserve the original behavior and clear intent, we can suggest using `if let`
```rust
for _ in f() {}
// turns into
if let Some(_) = f() {}
```
(P.S. `Some` and `Ok` are interchangeable depending on the type)
I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)!
Michael Howell [Mon, 10 Oct 2022 06:19:50 +0000 (23:19 -0700)]
rustdoc: clean up overly complex `.trait-impl` CSS selectors
When added in 45964368f4a2e31c94e9bcf1cef933c087d21544, these multi-class
selectors were present in the initial commit, but no reason was given why
the shorter selector wouldn't work.
bors [Mon, 10 Oct 2022 06:18:58 +0000 (06:18 +0000)]
Auto merge of #94381 - Kobzol:llvm-bolt, r=Mark-Simulacrum
Use BOLT in CI to optimize LLVM
This PR adds an optimization step in the Linux `dist` CI pipeline that uses [BOLT](https://github.com/llvm/llvm-project/tree/main/bolt) to optimize the `libLLVM.so` library built by boostrap.
Steps:
- [x] Use LLVM 15 as a bootstrap compiler and use it to build BOLT
- [x] Compile LLVM with support for relocations (`-DCMAKE_SHARED_LINKER_FLAGS="-Wl,-q"`)
- [x] Gather profile data using instrumented LLVM
- [x] Apply profile to LLVM that has already been PGOfied
- [x] Run with BOLT profiling on more benchmarks
- [x] Decide on the order of optimization (PGO -> BOLT?)
- [x] Decide how we should get `bolt` (currently we use the host `bolt`)
- [x] Clean up
The latest perf results can be found [here](https://github.com/rust-lang/rust/pull/94381#issuecomment-1258269440). The current CI build time with BOLT applied is around 1h 55 minutes.
Yuki Okushi [Mon, 10 Oct 2022 01:23:03 +0000 (10:23 +0900)]
Rollup merge of #102275 - Urgau:stabilize-half_open_range_patterns, r=cjgillot
Stabilize `half_open_range_patterns`
This PR stabilize `feature(half_open_range_patterns)`:
```
Allows using `..=X` as a pattern.
```
And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, https://github.com/rust-lang/rust/pull/102275#issuecomment-1267422806.
The FCP was completed in https://github.com/rust-lang/rust/issues/67264.
bors [Sun, 9 Oct 2022 21:02:33 +0000 (21:02 +0000)]
Auto merge of #89123 - the8472:push_in_capacity, r=amanieu
add Vec::push_within_capacity - fallible, does not allocate
This method can serve several purposes. It
* is fallible
* guarantees that items in Vec aren't moved
* allows loops that do `reserve` and `push` separately to avoid pulling in the allocation machinery a second time in the `push` part which should make things easier on the optimizer
* eases the path towards `ArrayVec` a bit since - compared to `push()` - there are fewer questions around how it should be implemented
I haven't named it `try_push` because that should probably occupy a middle ground that will still try to reserve and only return an error in the unlikely OOM case.
bors [Sun, 9 Oct 2022 18:15:26 +0000 (18:15 +0000)]
Auto merge of #102850 - JohnTitor:rollup-lze1w03, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #101118 (fs::get_mode enable getting the data via fcntl/F_GETFL on major BSD)
- #102072 (Add `ptr::Alignment` type)
- #102799 (rustdoc: remove hover gap in file picker)
- #102820 (Show let-else suggestion on stable.)
- #102829 (rename `ImplItemKind::TyAlias` to `ImplItemKind::Type`)
- #102831 (Don't use unnormalized type in `Ty::fn_sig` call in rustdoc `clean_middle_ty`)
- #102834 (Remove unnecessary `lift`/`lift_to_tcx` calls from rustdoc)
- #102838 (remove cfg(bootstrap) from Miri)
Yuki Okushi [Sun, 9 Oct 2022 15:09:42 +0000 (00:09 +0900)]
Rollup merge of #102829 - compiler-errors:rename-impl-item-kind, r=TaKO8Ki
rename `ImplItemKind::TyAlias` to `ImplItemKind::Type`
The naming of this variant seems inconsistent given that this is not really a "type alias", and the associated type variant for `TraitItemKind` is just called `Type`.
Yuki Okushi [Sun, 9 Oct 2022 15:09:41 +0000 (00:09 +0900)]
Rollup merge of #102820 - ehuss:let-else-nightly-suggestion, r=petrochenkov
Show let-else suggestion on stable.
The E0005 error message has a suggestion to use let-else. Now that let-else is stabilized, I think this message should be included on non-nightly toolchains. I suspect this was just an oversight from #93628. [`E0005.stderr`](https://github.com/ehuss/rust/blob/be1c7aad723126b2ea65543b4ceed54167b841a2/src/test/ui/error-codes/E0005.stderr#L22-L25) contains an example of what this suggestion looks like.
longe module names also wrap nicely:
<img width="389" alt="image" src="https://user-images.githubusercontent.com/29011024/194678516-f2497b3a-8d50-439b-9d69-3fa9fb43b84d.png">
Also if you zoom out very far, the arrows did move to the left, in relation to the text below. This is now also fixed.
<img width="818" alt="image" src="https://user-images.githubusercontent.com/29011024/194677652-cfdf129d-f5db-4f26-ac3c-3d0853e89619.png">
CSS doesn't have a lot of controll over the `::marker` element, so now the `::after` element is used to draw the arrows.
bors [Sun, 9 Oct 2022 15:07:10 +0000 (15:07 +0000)]
Auto merge of #93668 - SUPERCILEX:path_alloc, r=joshtriplett
Reduce CString allocations in std as much as possible
Currently, every operation involving paths in `fs` allocates memory to hold the path before sending it through the syscall. This PR instead uses a stack allocation (chosen size is somewhat arbitrary) when the path is short before falling back to heap allocations for long paths.
Benchmarks show that the stack allocation is ~2x faster for short paths:
```
test sys::unix::fd::tests::bench_heap_path_alloc ... bench: 34 ns/iter (+/- 2)
test sys::unix::fd::tests::bench_stack_path_alloc ... bench: 15 ns/iter (+/- 1)
```
For long paths, I couldn't find any measurable difference.
---
I'd be surprised if I was the first to think of this, so I didn't fully flush out the PR. If this change is desirable, I'll make use of `run_with_cstr` across all platforms in every fs method (currently just unix open for testing). I also added an `impl From<FromBytesWithNulError>` which is presumably a no-no (or at least needs to be done in another PR).
---
Also see https://github.com/nix-rust/nix/pull/1655 with a bunch of discussion where I'm doing something similar.
projects / rust.git / log