bors [Tue, 1 Jun 2021 00:51:00 +0000 (00:51 +0000)]
Auto merge of #85153 - cjgillot:qresolve, r=Aaron1011
Reduce the amount of untracked state in TyCtxt
Access to untracked global state may generate instances of #84970.
The GlobalCtxt contains the lowered HIR, the resolver outputs and interners.
By wrapping the resolver inside a query, we make sure those accesses are properly tracked.
As a no_hash query, all dependent queries essentially become `eval_always`,
what they should have been from the beginning.
bors [Mon, 31 May 2021 20:03:18 +0000 (20:03 +0000)]
Auto merge of #85702 - Aaron1011:no-vec-sort, r=michaelwoerister
Don't sort a `Vec` before computing its `DepTrackingHash`
Previously, we sorted the vec prior to hashing, making the hash
independent of the original (command-line argument) order. However, the
original vec was still always kept in the original order, so we were
relying on the rest of the compiler always working with it in an
'order-independent' way.
This assumption was not being upheld by the `native_libraries` query -
the order of the entires in its result depends on the order of entries
in `Options.libs`. This lead to an 'unstable fingerprint' ICE when the
`-l` arguments were re-ordered.
This PR removes the sorting logic entirely. Re-ordering command-line
arguments (without adding/removing/changing any arguments) seems like a
really niche use case, and correctly optimizing for it would require
additional work. By always hashing arguments in their original order, we
can entirely avoid a cause of 'unstable fingerprint' errors.
bors [Mon, 31 May 2021 07:32:50 +0000 (07:32 +0000)]
Auto merge of #85395 - 12101111:build-crt, r=petrochenkov
Build crtbegin.o/crtend.o from source code
Build crtbengin.o/crtend.o from source code instead of copying from gcc.
The crtbegin and crtend implementation from llvm don't need `crtbeginS.o` for PIC. `crtbegin{,S,T}.o` is unified into one generic `crtbegin.o`. See the comments in https://reviews.llvm.org/D28791#1419436 and https://reviews.llvm.org/D28791#1420914
bors [Mon, 31 May 2021 05:03:26 +0000 (05:03 +0000)]
Auto merge of #85819 - CDirkx:is_unicast_link_local_strict, r=joshtriplett
Remove `Ipv6Addr::is_unicast_link_local_strict`
Removes the unstable method `Ipv6Addr::is_unicast_link_local_strict` and keeps the behaviour of `Ipv6Addr::is_unicast_link_local`, see also #85604 where I have tried to summarize related discussion so far.
My intent is for `is_unicast_link_local`, `is_unicast_site_local` and `is_unicast_global` to have the semantics of checking if an address has Link-Local, Site-Local or Global scope, see also #85696 which changes the behaviour of `is_unicast_global` and renames these methods to `has_unicast_XXX_scope` to reflect this.
For checking Link-Local scope we currently have two methods: `is_unicast_link_local` and `is_unicast_link_local_strict`. This is because of what appears to be conflicting definitions in [IETF RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291).
With `is_unicast_link_local` checking `FE80::/10` and `is_unicast_link_local_strict` checking `FE80::/64`.
There is also [IETF RFC 5156 section 2.4](https://datatracker.ietf.org/doc/html/rfc5156#section-2.4) which defines "Link-Scoped Unicast" as `FE80::/10`.
It has been pointed out that implementations in other languages and the linux kernel all use `FE80::/10` (https://github.com/rust-lang/rust/pull/76098#issuecomment-706916840, https://github.com/rust-lang/rust/pull/76098#issuecomment-705928605).
Given all of this I believe the correct interpretation to be the following: All addresses in `FE80::/10` are defined as having Link-Local scope, however currently only the block `FE80::/64` has been allocated for "Link-Local IPv6 Unicast Addresses". This might change in the future however; more addresses in `FE80::/10` could be allocated and those will have Link-Local scope. I therefore believe the current behaviour of `is_unicast_link_local` to be correct (if interpreting it to have the semantics of `has_unicast_link_local_scope`) and `is_unicast_link_local_strict` to be unnecessary, confusing and even a potential source of future bugs:
Currently there is no real difference in checking `FE80::/10` or `FE80::/64`, since any address in practice will be `FE80::/64`. However if an application uses `is_unicast_link_local_strict` to implement link-local (so non-global) behaviour, it will be incorrect in the future if addresses outside of `FE80::/64` are allocated.
r? `@joshtriplett` as reviewer of all the related PRs
bors [Sun, 30 May 2021 20:20:44 +0000 (20:20 +0000)]
Auto merge of #85838 - GuillaumeGomez:rollup-rk2rh7m, r=GuillaumeGomez
Rollup of 8 pull requests
Successful merges:
- #85285 (Add eslint checks to CI)
- #85709 (Use correct edition when parsing `:pat` matchers)
- #85762 (Do not try to build LLVM with Zlib on Windows)
- #85770 (Remove `--print unversioned-files` from rustdoc )
- #85781 (Add documentation for aarch64-apple-ios-sim target)
- #85801 (Add `String::extend_from_within`)
- #85817 (Fix a typo)
- #85818 (Don't drop `PResult` without handling the error)
Guillaume Gomez [Sun, 30 May 2021 19:06:51 +0000 (21:06 +0200)]
Rollup merge of #85801 - WaffleLapkin:master, r=joshtriplett
Add `String::extend_from_within`
This PR adds `String::extend_from_within` function under the `string_extend_from_within` feature gate similar to the [`Vec::extend_from_within`] function.
We do not install Zlib on the CI but recent builds somehow started picking it's shared version.
To avoid relying on CI binaries so let's explicitly disable it.
Guillaume Gomez [Sun, 30 May 2021 19:06:44 +0000 (21:06 +0200)]
Rollup merge of #85709 - Aaron1011:fix-pat-crate-edition, r=petrochenkov
Use correct edition when parsing `:pat` matchers
As described in issue #85708, we currently do not properly decode
`SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a
result, when we decode a span from a foreign crate with
`SyntaxContext::root()`, we end up up considering it to have the edition
of the *current* crate, instead of the foreign crate where it was
originally created.
A full fix for this issue will be a fairly significant undertaking.
Fortunately, it's possible to implement a partial fix, which gives us
the correct edition-dependent behavior for `:pat` matchers when the
macro is loaded from another crate. Since we have the edition of the
macro's defining crate available, we can 'recover' from seeing a
`SyntaxContext::root()` and use the edition of the macro's defining
crate.
Any solution to issue #85708 must reproduce the behavior of this
targeted fix - properly preserving a foreign `SyntaxContext::root()`
means (among other things) preserving its edition, which by definition
is the edition of the foreign crate itself. Therefore, this fix moves us
closer to the correct overall solution, and does not expose any new
incorrect behavior to macros.
bors [Sun, 30 May 2021 17:39:45 +0000 (17:39 +0000)]
Auto merge of #85362 - jsgf:fix-emit-metadata, r=estebank
Use command line metadata path if provided
If the command-line has `--emit metadata=some/path/libfoo.rmeta` then
use that.
Closes #85356
I couldn't find any existing tests for the `--emit TYPE=PATH` command line syntax, so I wasn't sure how to test this aside from ad-hoc manual testing. Is there a ui test type for "generated output file with expected name"?
bors [Sun, 30 May 2021 07:25:38 +0000 (07:25 +0000)]
Auto merge of #85786 - GuillaumeGomez:error-code-checker-improvement, r=Mark-Simulacrum
Error code checker improvement
Just realized that some error codes shouldn't be ignored anymore. So I updated the script to ensure that if an error code is tested and ignored, it will trigger an error.
bors [Sun, 30 May 2021 01:21:39 +0000 (01:21 +0000)]
Auto merge of #83772 - jhpratt:revamp-step-trait, r=Mark-Simulacrum
Make `Step` trait safe to implement
This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,
1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.
All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.
Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.
bors [Sat, 29 May 2021 22:55:40 +0000 (22:55 +0000)]
Auto merge of #85390 - Mark-Simulacrum:fast-bridge, r=petrochenkov
Optimize proc macro bridge
This optimizes the proc macro bridge code for a win of 0.7% instruction counts on the diesel-check benchmark (non-incr, full). These wins are small, but hopefully not limited to just the diesel benchmark; the code is also not seriously impacted by the changes here.
bors [Sat, 29 May 2021 19:27:53 +0000 (19:27 +0000)]
Auto merge of #85698 - ehuss:incremental-session-panic, r=estebank
Don't panic when failing to initialize incremental directory.
This removes a panic when rustc fails to initialize the incremental directory. This can commonly happen on various filesystems that don't support locking (often various network filesystems). Panics can be confusing and scary, and there are already plenty of issues reporting this.
This has been panicking since 1.22 due to I think #44502 which was a major rework of how things work. Previously, things were simpler and the [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.21.0/src/librustc_incremental/persist/load.rs#L43-L65) function would emit an error and then continue on without panicking. With 1.22, [`load_dep_graph`](https://github.com/rust-lang/rust/blob/1.22.0/src/librustc_incremental/persist/load.rs#L44) was changed so that it assumes it can load the data without errors. Today, the problem is that it calls [`prepare_session_directory`](https://github.com/rust-lang/rust/blob/fbf1b1a7193cda17008ab590e06ad28d9924023b/compiler/rustc_interface/src/passes.rs#L175-L179) and then immediately calls `garbage_collect_session_directories` which will panic since the session is `IncrCompSession::NotInitialized`.
The solution here is to have `prepare_session_directory` return an error that must be handled so that compilation stops if it fails.
Some other options:
* Ignore directory lock failures.
* Print a warning on directory lock failure, but otherwise continue with incremental enabled.
* Print a warning on directory lock failure, and disable incremental.
* Provide a different locking mechanism.
Cargo ignores lock errors if locking is not supported, so that would be a precedent for the first option. These options would require quite a bit more changes, but I'm happy to entertain any of them, as I think they all have valid justifications.
There is more discussion on the many issues where this is reported: #49773, #59224, #66513, #76251. I'm not sure if this can be considered closing any of those, though, since I think there is some value in discussing if there is a way to avoid the error altogether. But I think it would make sense to at least close all but one to consolidate them.
Aaron Hill [Wed, 26 May 2021 03:58:42 +0000 (22:58 -0500)]
Use correct edition when parsing `:pat` matchers
As described in issue #85708, we currently do not properly decode
`SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a
result, when we decode a span from a foreign crate with
`SyntaxContext::root()`, we end up up considering it to have the edition
of the *current* crate, instead of the foreign crate where it was
originally created.
A full fix for this issue will be a fairly significant undertaking.
Fortunately, it's possible to implement a partial fix, which gives us
the correct edition-dependent behavior for `:pat` matchers when the
macro is loaded from another crate. Since we have the edition of the
macro's defining crate available, we can 'recover' from seeing a
`SyntaxContext::root()` and use the edition of the macro's defining
crate.
Any solution to issue #85708 must reproduce the behavior of this
targeted fix - properly preserving a foreign `SyntaxContext::root()`
means (among other things) preserving its edition, which by definition
is the edition of the foreign crate itself. Therefore, this fix moves us
closer to the correct overall solution, and does not expose any new
incorrect behavior to macros.
bors [Sat, 29 May 2021 16:27:14 +0000 (16:27 +0000)]
Auto merge of #85540 - GuillaumeGomez:better-result-dom-generation, r=jsha
Better result dom generation
First commit is from https://github.com/rust-lang/rust/pull/85506.
We realized in https://github.com/rust-lang/rust/pull/85506#issuecomment-844984162 thanks to `@dns2utf8` that in some cases, the generated search result DOM was invalid. This was not strict enough and the DOM was inserted as a big string, which wasn't great.
bors [Sat, 29 May 2021 13:34:20 +0000 (13:34 +0000)]
Auto merge of #85767 - lqd:stackless_span_stacks, r=oli-obk
A bit more polish on const eval errors
This PR adds a bit more polish to the const eval errors:
- a slight improvement to the PME messages from #85633: I mentioned there that the erroneous item's paths were dependent on the environment, and could be displayed fully qualified or not. This can obscure the items when they come from a dependency. This PR uses the pretty-printing code ensuring the items' paths are not trimmed.
- whenever there are generics involved in an item where const evaluation errors out, the error message now displays the instance and its const arguments, so that we can see which instantiated item and compile-time values lead to the error.
So we get this slight improvement for our beloved `stdarch` example, on nightly:
```
error[E0080]: evaluation of constant value failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', /rustc/9111b8ae9793f18179a1336417618fc07a9cac85/library/core/src/../../stdarch/crates/core_arch/src/macros.rs:8:9
|
```
to this PR's:
```
error[E0080]: evaluation of `core::core_arch::macros::ValidateConstImm::<51_i32, 0_i32, 15_i32>::VALID` failed
--> ./stdarch/crates/core_arch/src/macros.rs:8:9
|
8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
|
```
with this PR.
Of course this is an idea from Oli, so maybe r? `@oli-obk` if they have the time.
Waffle [Sat, 29 May 2021 07:36:30 +0000 (10:36 +0300)]
Add `String::extend_from_within`
This patch adds `String::extend_from_within` function under the
`string_extend_from_within` feature gate similar to the
`Vec::extend_from_within` function.
bors [Fri, 28 May 2021 15:03:52 +0000 (15:03 +0000)]
Auto merge of #85700 - Bobo1239:dso_local_ppc64, r=nagisa
Fix static relocation model for PowerPC64
We now also use `should_assume_dso_local()` for declarations and port two
additional cases from clang:
- Exclude PPC64 [1]
- Exclude thread-local variables [2]
Tbh I don't know enough about PowerPC(64) to explain why the TOC (table of contents; like the GOT in x86?) is still needed even with the static relocation model. But with these changes [Rust-For-Linux](https://github.com/Rust-for-Linux/linux) runs again on ppc64le. (instead of [getting loaded successfully but crashing](https://github.com/Bobo1239/linux/runs/2646478783?check_suite_focus=true#step:47:358))
bors [Fri, 28 May 2021 08:49:48 +0000 (08:49 +0000)]
Auto merge of #85546 - hyd-dev:unwind, r=RalfJung
const-eval: disallow unwinding across functions that `!fn_can_unwind()`
Following https://github.com/rust-lang/miri/pull/1776#discussion_r633074343, so r? `@RalfJung`
This PR turns `unwind` in `StackPopCleanup::Goto` into a new enum `StackPopUnwind`, with a `NotAllowed` variant to indicate that unwinding is not allowed. This variant is chosen based on `rustc_middle::ty::layout::fn_can_unwind()` in `eval_fn_call()` when pushing the frame. A check is added in `unwind_to_block()` to report UB if unwinding happens across a `StackPopUnwind::NotAllowed` frame.
bors [Fri, 28 May 2021 06:08:58 +0000 (06:08 +0000)]
Auto merge of #85745 - veber-alex:panic_any, r=m-ou-se
Add #[track_caller] to panic_any
Report the panic location from the user code.
```rust
use std::panic;
use std::panic::panic_any;
fn main() {
panic::set_hook(Box::new(|panic_info| {
if let Some(location) = panic_info.location() {
println!(
"panic occurred in file '{}' at line {}",
location.file(),
location.line(),
);
} else {
println!("panic occurred but can't get location information...");
}
}));
The current output is:
```
error[E0605]: non-primitive cast: `*mut (dyn T + 'static)` as `&dyn T`
--> src/main.rs:7:5
|
7 | (t as &dyn T).t();
| ^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
7 | (&t as &dyn T).t();
| ^
```
This is incorrect, though: The cast will _not_ be valid when writing `&t` instead of `t`:
```
error[E0277]: the trait bound `*mut (dyn T + 'static): T` is not satisfied
--> t4.rs:7:6
|
7 | (&t as &dyn T).t();
| ^^ the trait `T` is not implemented for `*mut (dyn T + 'static)`
|
= note: required for the cast to the object type `dyn T`
```
The correct suggestion is `&*t`, which I have implemented in this pull request. Of course, this suggestion will always require an unsafe block, but arguably, that's what the user really wants if they're trying to cast a pointer to a reference.
In any case, claiming that the cast will be valid after implementing the suggestion is overly optimistic, as the coercion logic doesn't seem to resolve all nested obligations, i.e. the cast may still be invalid after implementing the suggestion. I have therefore rephrased the suggestion slightly ("consider borrowing the value" instead of "borrow the value for the cast to be valid").
Additionally, I have fixed another incorrect suggestion not mentioned in #84598, which relates to casting immutable references to mutable ones:
```rust
fn main() {
let mut x = 0;
let m = &x as &mut i32;
}
```
currently leads to
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
3 | let m = &mut &x as &mut i32;
| ^^^^
```
which is obviously incorrect:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> t5.rs:3:13
|
3 | let m = &mut &x as &mut i32;
| ^^^^^^^ cannot borrow as mutable
```
I've changed the suggestion to a note explaining the problem:
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
note: this reference is immutable
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^
note: trying to cast to a mutable reference type
--> t5.rs:3:19
|
3 | let m = &x as &mut i32;
| ^^^^^^^^
```
In this example, it would have been even nicer to suggest replacing `&x` with `&mut x`, but this would be much more complex because we would have to take apart the expression to be cast (currently, we only look at its type), and `&x` could be stored in a variable, where such a suggestion would not even be directly applicable:
```rust
fn main() {
let mut x = 0;
let r = &x;
let m = r as &mut i32;
}
```
My solution covers this case, too.
We now also use `should_assume_dso_local()` for declarations and port two
additional cases from clang:
- Exclude PPC64 [1]
- Exclude thread-local variables [2]
bors [Fri, 28 May 2021 00:57:39 +0000 (00:57 +0000)]
Auto merge of #85743 - bjorn3:sync_cg_clif-2021-05-27, r=bjorn3
Sync rustc_codegen_cranelift
The main highlight this sync is the removal of several dependencies, making compilation of cg_clif itself faster. There have also been a couple of new features like `#[link_section]` now supporting different segments for Mach-O binaries (thanks `@eggyal!)` and the `imported_main` feature, which is currently unstable.
Mateusz Mikuła [Thu, 27 May 2021 21:12:15 +0000 (23:12 +0200)]
Do not try to build LLVM with Zlib on Windows
We do not install Zlib on the CI but recent builds somehow started picking it's shared version.
To avoid relying on CI binaries so let's explicitly disable it.
Add an alternative formatter to `libtest`. Formatter produces valid xml that later can be interpreted as JUnit report.
Caveats:
- `timestamp` is required by schema, but every viewer/parser ignores it. Attribute is not set to avoid depending on chrono;
- Running all "suits" (unit tests, doc-tests and integration tests) will produce a mess;
- I couldn't find a way to get integration test binary name, so it's just goes by "integration";
Guillaume Gomez [Thu, 27 May 2021 18:08:17 +0000 (20:08 +0200)]
Rollup merge of #85722 - GuillaumeGomez:trait-toggle, r=jsha
Fix trait methods' toggle
A `<details>` tag wasn't closed on trait methods, which created broken DOM. I also used this occasion to only generate the toggle in case there is documentation on the method.
projects / rust.git / log