Aaron Hill [Thu, 12 Aug 2021 20:30:40 +0000 (15:30 -0500)]
Include (potentially remapped) working dir in crate hash
Fixes #85019
A `SourceFile` created during compilation may have a relative
path (e.g. if rustc itself is invoked with a relative path).
When we write out crate metadata, we convert all relative paths
to absolute paths using the current working direction.
However, the working directory is not included in the crate hash.
This means that the crate metadata can change while the crate
hash remains the same. Among other problems, this can cause a
fingerprint mismatch ICE, since incremental compilation uses
the crate metadata hash to determine if a foreign query is green.
This commit moves the field holding the working directory from
`Session` to `Options`, including it as part of the crate hash.
Erin Power [Fri, 30 Jul 2021 11:32:16 +0000 (13:32 +0200)]
Update RELEASES.md for 1.55.0
Co-authored-by: Eric Huss <eric@huss.org> Co-authored-by: inquisitivecrystal <22333129+inquisitivecrystal@users.noreply.github.com> Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com> Co-authored-by: Daniel Giger <danielg3432@gmail.com>
bors [Sun, 15 Aug 2021 10:56:35 +0000 (10:56 +0000)]
Auto merge of #86692 - dns2utf8:parallelize_rustdoc-gui_tests, r=GuillaumeGomez
Run rustdoc-gui tests in parallel
I hid the passing tests and only show the failed ones in alphabetical order:
![image](https://user-images.githubusercontent.com/739070/123663020-84e63100-d825-11eb-9b35-0a8c30cd219c.png)
Also this PR cuts down the execution time from ~40 to ~9 seconds
bors [Sun, 15 Aug 2021 04:48:42 +0000 (04:48 +0000)]
Auto merge of #87974 - steffahn:slice_split_size_hints, r=dtolnay
Test and fix `size_hint` for slice’s [r]split* iterators
Adds extensive test (of `size_hint`) for all the _[r]split*_ iterators.
Fixes `size_hint` upper bound for _split_inclusive*_ iterators which was one higher than necessary for non-empty slices.
Fixes `size_hint` lower bound for _[r]splitn*_ iterators when _n == 0_, which was one too high.
**Lower bound being one too high was a logic error, violating the correctness condition of `size_hint`.**
_Edit:_ I’ve opened an issue for that bug, so this PR fixes #87978
bors [Sat, 14 Aug 2021 17:33:38 +0000 (17:33 +0000)]
Auto merge of #87324 - asquared31415:named-asm-labels, r=Amanieu
Lint against named asm labels
This adds a deny-by-default lint to prevent the use of named labels in inline `asm!`. Without a solution to #81088 about whether the compiler should rewrite named labels or a special syntax for labels, a lint against them should prevent users from writing assembly that could break for internal compiler reasons, such as inlining or anything else that could change the number of actual inline assembly blocks emitted.
This does **not** resolve the issue with rewriting labels, that still needs a decision if the compiler should do any more work to try to make them work.
bors [Sat, 14 Aug 2021 12:06:34 +0000 (12:06 +0000)]
Auto merge of #87375 - fee1-dead:move-constness-to-traitpred, r=oli-obk
Try filtering out non-const impls when we expect const impls
**TL;DR**: Associated types on const impls are now bounded; we now disallow calling a const function with bounds when the specified type param only has a non-const impl.
Some notes:
- backtrace-debuginfo.rs: previously I skipped this, I'm still not sure what the best dir is. Any ideas?
- estr-subtyping.rs: Seems a quite old test so removed, shouldn't?
- deref-suggestion.rs: moved to inference as `suggestions` is not an ideal dir.
- issue-43023.rs: a bit misclassified, moved to `derives`
bors [Sat, 14 Aug 2021 07:01:36 +0000 (07:01 +0000)]
Auto merge of #85020 - lrh2000:named-upvars, r=tmandry
Name the captured upvars for closures/generators in debuginfo
Previously, debuggers print closures as something like
```
y::main::closure-0 (0x7fffffffdd34)
```
The pointer actually references to an upvar. It is not very obvious, especially for beginners.
It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like
```
y::main::closure-0 {_captured_ref__b: 0x[...]}
```
r? `@tmandry`
Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 .
bors [Sat, 14 Aug 2021 01:12:22 +0000 (01:12 +0000)]
Auto merge of #87997 - sl4m:update-favicon-order, r=GuillaumeGomez
Updates favicon order of precedence as it matters to Chrome
Hi, this updates #75438 to fix an order of precedence issue for Chrome. Unfortunately, the last favicon defined wins when it comes to Chrome, hence the primary icon being placed last. I [brought it up](https://bugs.chromium.org/p/chromium/issues/detail?id=1104663) with the Chromium team last year, but so far it's a non-issue.
I've created an example website that mimics the behaviour in Chrome. https://sl4m.github.io/chrome-favicon/
This is what I'm seeing at the moment when viewing https://doc.rust-lang.org/core/index.html in Chrome. It's falling back to the PNG.
<img width="80" alt="Screenshot 2021-08-12 at 21 11 58" src="https://user-images.githubusercontent.com/47347/129304041-b598213e-fcd3-4df1-addb-e6feac6c35b1.png">
This PR fixes the problem, by adding associated functions that have "custom linkage" to `reachable_set`, just like normal functions.
I haven't tested whether #76211 and [Miri](https://github.com/rust-lang/miri/issues/1837) are fixed by this PR yet, but I'm submitting this anyway since this fixes the examples above.
I added a `run-pass` test that combines my two examples above, but I'm not sure if that's the right way to test this. Maybe I should add / modify an existing codegen test (`src/test/codegen/export-no-mangle.rs`?) instead?
Dan Gohman [Fri, 13 Aug 2021 15:58:05 +0000 (08:58 -0700)]
Change WASI's `RawFd` from `u32` to `c_int` (`i32`).
WASI previously used `u32` as its `RawFd` type, since its "file descriptors"
are unsigned table indices, and there's no fundamental reason why WASI can't
have more than 2^31 handles.
However, this creates myriad little incompability problems with code
that also supports Unix platforms, where `RawFd` is `c_int`. While WASI
isn't a Unix, it often shares code with Unix, and this difference made
such shared code inconvenient. #87329 is the most recent example of such
code.
So, switch WASI to use `c_int`, which is `i32`. This will mean that code
intending to support WASI should ideally avoid assuming that negative file
descriptors are invalid, even though POSIX itself says that file descriptors
are never negative.
This is a breaking change, but `RawFd` is considerd an experimental
feature in [the documentation].
Joshua Nelson [Fri, 13 Aug 2021 16:03:17 +0000 (11:03 -0500)]
Enable `--all-targets` for `x.py check` unconditionally
Now that Cargo deduplicates diagnostics from different targets, this doesn't flood the console with
duplicate errors.
Note that this doesn't add `--all-targets` in `Builder::cargo` directly because `impl Step for Std`
actually wants to omit `--all-targets` the first time while it's still building libtest.
When passed `--all-targets`, this warns that the option isn't needed, but still continues to compile.
Guillaume Gomez [Fri, 13 Aug 2021 13:29:11 +0000 (15:29 +0200)]
Rollup merge of #87966 - pietroalbini:fix-pidfd-test, r=m-ou-se
Fix `command-create-pidfd` test inside unprivileged Docker containers
In `src/test/ui/command/command-create-pidfd.rs` (added #81825), the detection code to skip the test on unsupported platforms doesn't account for unprivileged Docker containers (CI uses privileged containers), which leads to a test failure as you can't call the `clone3` syscall in that environment. This PR enhances the detection code to also consider unprivileged containers.
Guillaume Gomez [Fri, 13 Aug 2021 13:29:10 +0000 (15:29 +0200)]
Rollup merge of #87795 - estebank:erase-lifetimes-in-suggestion, r=oli-obk
Avoid ICE caused by suggestion
When suggesting dereferencing something that can be iterable in a `for`
loop, erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region
constraints already solved' panic.
Before:
```
warning: changes to closure capture in Rust 2021 will affect drop order
--> src/main.rs:5:13
|
5 | let _ = || panic!(a.0);
| ^^^^^^^^^^---^
| |
| in Rust 2018, closure captures all of `a`, but in Rust 2021, it only captures `a.0`
6 | }
| - in Rust 2018, `a` would be dropped here, but in Rust 2021, only `a.0` would be dropped here alongside the closure
|
help: add a dummy let to cause `a` to be fully captured
|
20~ ($msg:expr $(,)?) => ({ let _ = &a;
21+ $crate::rt::begin_panic($msg)
22~ }),
|
```
After:
```
warning: changes to closure capture in Rust 2021 will affect drop order
--> src/main.rs:5:13
|
5 | let _ = || panic!(a.0);
| ^^^^^^^^^^---^
| |
| in Rust 2018, closure captures all of `a`, but in Rust 2021, it only captures `a.0`
6 | }
| - in Rust 2018, `a` would be dropped here, but in Rust 2021, only `a.0` would be dropped here alongside the closure
|
help: add a dummy let to cause `a` to be fully captured
|
5 | let _ = || { let _ = &a; panic!(a.0) };
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Aaron Hill [Thu, 12 Aug 2021 20:11:21 +0000 (15:11 -0500)]
Prevent double panic when handling incremental fingerprint mismatch
When an incremental fingerprint mismatch occurs, we debug-print
our `DepNode` and query result. Unfortunately, the debug printing
process may cause us to run additional queries, which can result
in a re-entrant fingerprint mismatch error.
To avoid a double panic, this commit adds a thread-local variable
to detect re-entrant calls.
Rollup merge of #87965 - m-ou-se:non-fmt-panic-external, r=estebank
Silence non_fmt_panic from external macros.
This stops the non_fmt_panic lint from triggering if a macro from another crate is entirely responsible. In those cases there's nothing that the current crate can/should do.
See also https://github.com/rust-lang/rust/issues/87621#issuecomment-890311054