bors [Sun, 21 Nov 2021 10:19:33 +0000 (10:19 +0000)]
Auto merge of #91104 - matthiaskrgr:rollup-duk33o1, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #91008 (Adds IEEE 754-2019 minimun and maximum functions for f32/f64)
- #91070 (Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`)
- #91097 (Add spaces in opaque `impl Trait` with more than one trait)
- #91098 (Don't suggest certain fixups (`.field`, `.await`, etc) when reporting errors while matching on arrays )
Matthias Krüger [Sun, 21 Nov 2021 08:55:16 +0000 (09:55 +0100)]
Rollup merge of #91098 - compiler-errors:issue-91058, r=estebank
Don't suggest certain fixups (`.field`, `.await`, etc) when reporting errors while matching on arrays
When we have a type mismatch with a `cause.code` that is an `ObligationCauseCode::Pattern`, skip suggesting fixes like adding `.await` or accessing a struct's `.field` if the pattern's `root_ty` differs from the `expected` ty. This occurs in situations like this:
```rust
struct S(());
fn main() {
let array = [S(())];
match array {
[()] => {}
_ => {}
}
}
```
I think what's happening here is a layer of `[_; N]` is peeled off of both types and we end up seeing the mismatch between just `S` and `()`, but when we suggest a fixup, that applies to the expression with type `root_ty`.
---
Questions:
1. Should this check live here, above all of the suggestions, or should I push this down into every suggestion when we match `ObligationCauseCode`?
2. Any other `ObligationCauseCode`s to check here?
3. Am I overlooking an easier way to get to this same conclusion without pattern matching on `ObligationCauseCode` and comparing `root_ty`?
Matthias Krüger [Sun, 21 Nov 2021 08:55:14 +0000 (09:55 +0100)]
Rollup merge of #91070 - cuviper:insert-global, r=nagisa
Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`
`Module::getOrInsertGlobal` returns a `Constant*`, which is a super
class of `GlobalVariable`, but if the given type doesn't match an
existing declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to `LLVMGetVisibility` which
unconditionally casts the opaque argument to a `GlobalValue*`.
Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from `rustc_codegen_llvm` instead.
Matthias Krüger [Sun, 21 Nov 2021 08:55:13 +0000 (09:55 +0100)]
Rollup merge of #91008 - Urgau:float-minimum-maximum, r=scottmcm
Adds IEEE 754-2019 minimun and maximum functions for f32/f64
IEEE 754-2019 removed the `minNum` (`min` in Rust) and `maxNum` (`max` in Rust) operations in favor of the newly created `minimum` and `maximum` operations due to their [non-associativity](https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf) that cannot be fix in a backwards compatible manner. This PR adds `fN::{minimun,maximum}` functions following the new rules.
### IEEE 754-2019 Rules
> **minimum(x, y)** is x if x < y, y if y < x, and a quiet NaN if either operand is a NaN, according to 6.2.
For this operation, −0 compares less than +0. Otherwise (i.e., when x = y and signs are the same)
it is either x or y.
> **maximum(x, y)** is x if x > y, y if y > x, and a quiet NaN if either operand is a NaN, according to 6.2.
For this operation, +0 compares greater than −0. Otherwise (i.e., when x = y and signs are the
same) it is either x or y.
"IEEE Standard for Floating-Point Arithmetic," in IEEE Std 754-2019 (Revision of IEEE 754-2008) , vol., no., pp.1-84, 22 July 2019, doi: 10.1109/IEEESTD.2019.8766229.
### Implementation
This implementation is inspired by the one in [`glibc` ](https://github.com/bminor/glibc/blob/90f0ac10a74b2d43b5a65aab4be40565e359be43/math/s_fminimum_template.c) (it self derived from the C2X draft) expect that:
- it doesn't use `copysign` because it's not available in `core` and also because `copysign` is unnecessary (we only want to check the sign, no need to create a new float)
- it also prefer `other > self` instead of `self < other` like IEEE 754-2019 does
I originally tried to implement them [using intrinsics](https://github.com/Urgau/rust/commit/1d8aa13bc39eeef1afba0524dc5ea10d073522e6) but LLVM [error out](https://godbolt.org/z/7sMrxW49a) when trying to lower them to machine intructions, GCC doesn't yet have built-ins for them, only cranelift support them nativelly (as it doesn't support the nativelly the old sementics).
Helps with https://github.com/rust-lang/rust/issues/83984
bors [Sun, 21 Nov 2021 07:15:32 +0000 (07:15 +0000)]
Auto merge of #89580 - estebank:trait-bounds-are-tricky, r=nagisa
Point at source of trait bound obligations in more places
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
We no longer point at associated items (`ImplObligation`), as they didn't
add any user actionable information, they just added noise.
bors [Sat, 20 Nov 2021 21:40:43 +0000 (21:40 +0000)]
Auto merge of #91093 - matthiaskrgr:rollup-kovzwx0, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #89741 (Mark `Arc::from_inner` / `Rc::from_inner` as unsafe)
- #90927 (Fix float ICE)
- #90994 (Fix ICE `#90993`: add missing call to cancel)
- #91018 (Adopt let_else in more places in rustc_mir_build)
- #91022 (Suggest `await` in more situations where infer types are involved)
- #91088 (Revert "require full validity when determining the discriminant of a value")
Matthias Krüger [Sat, 20 Nov 2021 21:33:51 +0000 (22:33 +0100)]
Rollup merge of #91022 - compiler-errors:modulo_infer, r=estebank
Suggest `await` in more situations where infer types are involved
Currently we use `TyS::same_type` in diagnostics that suggest adding `.await` to opaque future types.
This change makes the suggestion slightly more general, when we're comparing types like `Result<T, E>` and `Result<_, _>` which happens sometimes in places like `match` patterns or `let` statements with partially-elaborated types.
----
Question:
1. Is this change worthwhile? Totally fine if it doesn't make sense adding.
2. Should `same_type_modulo_infer` live in `rustc_infer::infer::error_reporting` or alongside the other method in `rustc_middle::ty::util`?
3. Should we generalize this change? I wanted to change all usages, but I don't want erroneous suggestions when adding `.field_name`...
Esteban Kuber [Tue, 5 Oct 2021 23:04:09 +0000 (23:04 +0000)]
Point at source of trait bound obligations in more places
Be more thorough in using `ItemObligation` and `BindingObligation` when
evaluating obligations so that we can point at trait bounds that
introduced unfulfilled obligations. We no longer incorrectly point at
unrelated trait bounds (`substs-ppaux.verbose.stderr`).
In particular, we now point at trait bounds on method calls.
We no longer point at "obvious" obligation sources (we no longer have a
note pointing at `Trait` saying "required by a bound in `Trait`", like
in `associated-types-no-suitable-supertrait*`).
bors [Sat, 20 Nov 2021 18:23:11 +0000 (18:23 +0000)]
Auto merge of #87704 - ChrisDenton:win-resolve-exe, r=yaahc
Windows: Resolve `process::Command` program without using the current directory
Currently `std::process::Command` searches many directories for the executable to run, including the current directory. This has lead to a [CVE for `ripgrep`](https://cve.circl.lu/cve/CVE-2021-3013) but presumably other command line utilities could be similarly vulnerable if they run commands. This was [discussed on the internals forum](https://internals.rust-lang.org/t/std-command-resolve-to-avoid-security-issues-on-windows/14800). Also discussed was [which directories should be searched](https://internals.rust-lang.org/t/windows-where-should-command-new-look-for-executables/15015).
EDIT: This PR originally removed all implicit paths. They've now been added back as laid out in the rest of this comment.
## Old Search Strategy
The old search strategy is [documented here][1]. Additionally Rust adds searching the child's paths (see also #37519). So the full list of paths that were searched was:
1. The directories that are listed in the child's `PATH` environment variable.
2. The directory from which the application loaded.
3. The current directory for the parent process.
4. The 32-bit Windows system directory.
5. The 16-bit Windows system directory.
6. The Windows directory.
7. The directories that are listed in the PATH environment variable.
## New Search Strategy
The new strategy removes the current directory from the searched paths.
1. The directories that are listed in the child's PATH environment variable.
2. The directory from which the application loaded.
3. The 32-bit Windows system directory.
4. The Windows directory.
5. The directories that are listed in the parent's PATH environment variable.
Note that it also removes the 16-bit system directory, mostly because there isn't a function to get it. I do not anticipate this being an issue in modern Windows.
## Impact
Removing the current directory should fix CVE's like the one linked above. However, it's possible some Windows users of affected Rust CLI applications have come to expect the old behaviour.
This change could also affect small Windows-only script-like programs that assumed the current directory would be used. The user would need to use `.\file.exe` instead of the bare application name.
This PR could break tests, especially those that test the exact output of error messages (e.g. Cargo) as this does change the error messages is some cases.
Before (cut relevant part of output):
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future`
```
After:
```
note: while checking the return type of the `async fn`
--> /home/michael/test.rs:5:19
|
5 | async fn bar() -> usize {
| ^^^^^ checked the `Output` of this `async fn`, found opaque type
= note: expected type `usize`
found opaque type `impl Future<Output = usize>`
```
Note the "found opaque type `impl Future<Output = usize>`" in the new output.
----
Questions:
1. We skip printing the output type when it's a projection, since I have been seeing some types like `impl Future<Output = <[static generator@/home/michael/test.rs:2:11: 2:21] as Generator<ResumeTy>>::Return>` which are not particularly helpful and leak implementation detail.
* Am I able to normalize this type within `rustc_middle::ty::print::pretty`? Alternatively, can we normalize it when creating the diagnostic? Otherwise, I'm fine with skipping it and falling back to the old output.
* Should I suppress any other types? I didn't encounter anything other than this generator projection type.
2. Not sure what the formatting of this should be. Do I include spaces in `Output = `?
Sadly, I wasn't able to add a GUI test to ensure that the scrollbar was always displayed because it seems not possible in puppeteer for whatever reason... I used this method: on small pages (like `lib2/sub_mod/index.html`), comparing `.navbar`'s `clientWidth` with `offsetWidth` (the first doesn't include the sidebar in the computed amount). When checking in the browser, it works fine but in puppeteer it almost never works...
In case anyone want to try to solve the bug, here is the puppeteer code:
<details>
More information about this: I tried another approach which was to get the element in `evaluate` directly (by calling it from `page.evaluate(() => { .. });` directly instead of `parseAssertElemProp.evaluate(e => {...});`.
Matthias Krüger [Sat, 20 Nov 2021 09:21:14 +0000 (10:21 +0100)]
Rollup merge of #90930 - Nilstrieb:fix-non-const-value-ice, r=estebank
Fix `non-constant value` ICE (#90878)
This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.
I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.
Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.
Asking Esteban to review since he was the last one to change the relevant code.
Matthias Krüger [Sat, 20 Nov 2021 09:21:13 +0000 (10:21 +0100)]
Rollup merge of #90628 - ken-matsui:clarify-error-messages-caused-by-reexporting-pub-crate-visibility-to-outside, r=oli-obk
Clarify error messages caused by re-exporting `pub(crate)` visibility to outside
This PR clarifies error messages and suggestions caused by re-exporting pub(crate) visibility outside the crate.
Here is a small example ([Rust Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e2cd0bd4422d4f20e6522dcbad167d3b)):
```rust
mod m {
pub(crate) enum E {}
}
pub use m::E;
fn main() {}
```
This code is compiled to:
```
error[E0365]: `E` is private, and cannot be re-exported
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of private `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
However, enum `E` is actually public to the crate, not private totally—nevertheless, rustc treats `pub(crate)` and private visibility as the same on the error messages. They are not clear and should be segmented distinctly.
By applying changes in this PR, the error message below will be the following message that would be clearer:
```
error[E0365]: `E` is only public to inside of the crate, and cannot be re-exported outside
--> prog.rs:4:9
|
4 | pub use m::E;
| ^^^^ re-export of crate public `E`
|
= note: consider declaring type or module `E` with `pub`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0365`.
```
Josh Stone [Sat, 20 Nov 2021 03:33:29 +0000 (19:33 -0800)]
Make `LLVMRustGetOrInsertGlobal` always return a `GlobalVariable`
`Module::getOrInsertGlobal` returns a `Constant*`, which is a super
class of `GlobalVariable`, but if the given type doesn't match an
existing declaration, it returns a bitcast of that global instead.
This causes UB when we pass that to `LLVMGetVisibility` which
unconditionally casts the opaque argument to a `GlobalValue*`.
Instead, we can do our own get-or-insert without worrying whether
existing types match exactly. It's not relevant when we're just trying
to get/set the linkage and visibility, and if types are needed we can
bitcast or error nicely from `rustc_codegen_llvm` instead.
bors [Sat, 20 Nov 2021 01:06:27 +0000 (01:06 +0000)]
Auto merge of #91064 - matthiaskrgr:rollup-2ijidpt, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #88361 (Makes docs for references a little less confusing)
- #90089 (Improve display of enum variants)
- #90956 (Add a regression test for #87573)
- #90999 (fix CTFE/Miri simd_insert/extract on array-style repr(simd) types)
- #91026 (rustdoc doctest: detect `fn main` after an unexpected semicolon)
- #91035 (Put back removed empty line)
- #91044 (Turn all 0x1b_u8 into '\x1b' or b'\x1b')
- #91054 (rustdoc: Fix some unescaped HTML tags in docs)
Matthias Krüger [Sat, 20 Nov 2021 00:09:42 +0000 (01:09 +0100)]
Rollup merge of #91026 - notriddle:notriddle/rustdoc-doctest-semicolon, r=jyn514
rustdoc doctest: detect `fn main` after an unexpected semicolon
Fixes #91014
The basic problem with this is that rustdoc, when hunting for `fn main`, will stop parsing after it reaches a fatal error. This unexpected semicolon was a fatal error, so in `src/test/rustdoc-ui/failed-doctest-extra-semicolon-on-item.rs`, it would wrap the doctest in an implied main function, turning it into this:
This, as it turns out, is totally valid, and it executes no assertions, so *it passes,* even though the user wanted it to execute the assertion.
The Rust parser already has the ability to recover from these unexpected semicolons, but to do so, it needs to use the `parse_mod` function, so this PR changes it to do that.
Matthias Krüger [Sat, 20 Nov 2021 00:09:41 +0000 (01:09 +0100)]
Rollup merge of #90999 - RalfJung:miri_simd, r=oli-obk
fix CTFE/Miri simd_insert/extract on array-style repr(simd) types
The changed test would previously fail since `place_index` would just return the only field of `f32x4`, i.e., the array -- rather than *indexing into* the array which is what we have to do.
The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912.
Matthias Krüger [Sat, 20 Nov 2021 00:09:38 +0000 (01:09 +0100)]
Rollup merge of #90089 - jsha:enum-fields-headings, r=camelid,GuillaumeGomez
Improve display of enum variants
Use h3 and h4 for the variant name and the "Fields" subheading.
Remove the "of T" part of the "Fields" subheading.
Remove border-bottom from "Fields" subheading.
Move docblock below "Fields" listing.
Matthias Krüger [Sat, 20 Nov 2021 00:09:37 +0000 (01:09 +0100)]
Rollup merge of #88361 - WaffleLapkin:patch-2, r=jyn514
Makes docs for references a little less confusing
- Make clear that the `Pointer` trait is related to formatting
- Make clear that the `Pointer` trait is implemented for references (previously it was confusing to first see that it's implemented and then see it in "expect")
- Make clear that `&T` (shared reference) implements `Send` (if `T: Send + Sync`)
It speeds up hashing for `Obligation` [deduplication](https://github.com/rust-lang/rust/blob/c9c4b5d7276297679387189d96a952f2b760e7ad/compiler/rustc_trait_selection/src/traits/select/mod.rs#L2355-L2356) by only hashing the discriminant of the `ObligationCauseCode` enum instead of its contents. That shouldn't affect hash quality much since there are several other fields in `Obligation` which should be unique enough, especially the predicate itself which is hashed as an interned pointer.
bors [Fri, 19 Nov 2021 06:13:29 +0000 (06:13 +0000)]
Auto merge of #91033 - JohnTitor:rollup-sr9zg6o, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #89258 (Make char conversion functions unstably const)
- #90578 (add const generics test)
- #90633 (Refactor single variant `Candidate` enum into a struct)
- #90800 (bootstap: create .cargo/config only if not present)
- #90942 (windows: Return the "Not Found" error when a path is empty)
- #90947 (Move some tests to more reasonable directories - 9.5)
- #90961 (Suggest removal of arguments for unit variant, not replacement)
- #90990 (Arenas cleanup)
Yuki Okushi [Fri, 19 Nov 2021 04:06:35 +0000 (13:06 +0900)]
Rollup merge of #90800 - aplanas:fix_cargo_config, r=Mark-Simulacrum
bootstap: create .cargo/config only if not present
In some situations we should want on influence into the .cargo/config
when we use vendored source. One example is #90764, when we want to
workaround some references to crates forked and living in git, that are
missing in the vendor/ directory.
This commit will create the .cargo/config file only when the .cargo/
directory needs to be created.
Yuki Okushi [Fri, 19 Nov 2021 04:06:31 +0000 (13:06 +0900)]
Rollup merge of #89258 - est31:const_char_convert, r=oli-obk
Make char conversion functions unstably const
The char conversion functions like `char::from_u32` do trivial computations and can easily be converted into const fns. Only smaller tricks are needed to avoid non-const standard library functions like `Result::ok` or `bool::then_some`.
bors [Thu, 18 Nov 2021 23:54:14 +0000 (23:54 +0000)]
Auto merge of #90774 - alexcrichton:tweak-const, r=m-ou-se
std: Tweak expansion of thread-local const
This commit tweaks the expansion of `thread_local!` when combined with a
`const { ... }` value to help ensure that the rules which apply to
`const { ... }` blocks will be the same as when they're stabilized.
Previously with this invocation:
thread_local!(static NAME: Type = const { init_expr });
this would generate (on supporting platforms):
#[thread_local]
static NAME: Type = init_expr;
instead the macro now expands to:
const INIT_EXPR: Type = init_expr;
#[thread_local]
static NAME: Type = INIT_EXPR;
with the hope that because `init_expr` is defined as a `const` item then
it's not accidentally allowing more behavior than if it were put into a
`static`. For example on the stabilization issue [this example][ex] now
gives the same error both ways.
Michael Howell [Thu, 18 Nov 2021 23:15:12 +0000 (16:15 -0700)]
rustdoc doctest: detect `fn main` after an unexpected semicolon
The basic problem with this is that rustdoc, when hunting for `fn main`, will stop
parsing after it reaches a fatal error. This unexpected semicolon was a fatal error,
so in `src/test/rustdoc-ui/failed-doctest-extra-semicolon-on-item.rs`, it would wrap
the doctest in an implied main function, turning it into this:
This, as it turns out, is totally valid, and it executes no assertions, so *it passes,*
even though the user wanted it to execute the assertion.
The Rust parser already has the ability to recover from these unexpected semicolons,
but to do so, it needs to use the `parse_mod` function, so this commit changes it to do that.
bors [Thu, 18 Nov 2021 20:23:26 +0000 (20:23 +0000)]
Auto merge of #91019 - JohnTitor:rollup-q95ra7r, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #90386 (Add `-Zassert-incr-state` to assert state of incremental cache)
- #90438 (Clean up mess for --show-coverage documentation)
- #90480 (Mention `Vec::remove` in `Vec::swap_remove`'s docs)
- #90607 (Make slice->str conversion and related functions `const`)
- #90750 (rustdoc: Replace where-bounded Clean impl with simple function)
- #90895 (require full validity when determining the discriminant of a value)
- #90989 (Avoid suggesting literal formatting that turns into member access)
- #91002 (rustc: Remove `#[rustc_synthetic]`)
Yuki Okushi [Thu, 18 Nov 2021 17:22:59 +0000 (02:22 +0900)]
Rollup merge of #91002 - petrochenkov:nosynth, r=davidtwco
rustc: Remove `#[rustc_synthetic]`
This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.
Noticed while reviewing https://github.com/rust-lang/rust/pull/90947.
Yuki Okushi [Thu, 18 Nov 2021 17:22:58 +0000 (02:22 +0900)]
Rollup merge of #90895 - RalfJung:read-discriminant-valid, r=oli-obk
require full validity when determining the discriminant of a value
This resolves (for now) the semantic question that came up in https://github.com/rust-lang/rust/pull/89764: arguably, reading the discriminant of a value is 'using' that value, so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just "doing their job".
The alternative would be to just require that the discriminant itself is valid, if any -- but then what do we do for types that do not have a discriminant, which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types, but I would rather not special case that.
I don't think this can be tested in CTFE (since validity is not enforced there), I will add a compile-fail test to Miri:
```rust
#[allow(enum_intrinsics_non_enums)]
fn main() {
let i = 2u8;
std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB
}
```
(I tried running the check even on the CTFE machines, but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp, but that simply does not seem worth the effort currently.)
Yuki Okushi [Thu, 18 Nov 2021 17:22:57 +0000 (02:22 +0900)]
Rollup merge of #90750 - camelid:rm-tuple-impls-1, r=jyn514
rustdoc: Replace where-bounded Clean impl with simple function
This is the first step in removing the Clean impls for tuples. Either way, this
significantly simplifies the code since it reduces the amount of "trait magic".
(To clarify, I'm referring to impls like `impl Clean for (A, B)`, not Clean impls
that work on tuples in the user's program.)
I'm not sure why `from_utf8_unchecked_mut` was left out being non-`const`, considering that `from_utf8_unchecked` is not only `const`, but **`const` stable**.
projects / rust.git / log