Matthias Krüger [Tue, 7 Feb 2023 16:57:14 +0000 (17:57 +0100)]
Rollup merge of #107555 - edward-shen:edward-shen/dup-trait-suggestion, r=compiler-errors
Modify existing bounds if they exist
Fixes #107335.
This implementation is kinda gross but I don't really see a better way to do it.
This primarily does two things: Modifies `suggest_constraining_type_param` to accept a new parameter that indicates a span to be replaced instead of added, if presented, and limit the additive suggestions to either suggest a new bound on an existing bound (see newly added unit test) or add the generics argument if a generics argument wasn't found.
The former change is required to retain the capability to add an entirely new bounds if it was entirely omitted.
bors [Tue, 7 Feb 2023 09:58:58 +0000 (09:58 +0000)]
Auto merge of #107704 - jyn514:tidy-ci, r=Mark-Simulacrum
Run `expand-yaml-anchors` in `x test tidy`
Previously, the pre-commit hook which runs `x test tidy` could pass only to have CI fail within the first 30 seconds. This adds about 30 seconds to `test tidy` (for an initial run, much less after the tool is built the first time) in exchange for catching errors in `.github/workflows/ci.yml` before they're pushed.
bors [Tue, 7 Feb 2023 03:35:10 +0000 (03:35 +0000)]
Auto merge of #106180 - RalfJung:dereferenceable-generators, r=nbdd0121
make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias
See https://github.com/rust-lang/unsafe-code-guidelines/issues/381 and [this LLVM discussion](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979). The exact semantics of how `noalias` and `dereferenceable` interact are unclear, and `@comex` found a case of LLVM actually exploiting that ambiguity for optimizations. I think for now we should treat LLVM `dereferenceable` as implying a "fake read" to happen immediately at the top of the function (standing in for the spurious reads that LLVM might introduce), and that fake read is subject to all the usual `noalias` restrictions. This means we cannot put `dereferenceable` on `&mut !Unpin` references as those references can alias with other references that are being read and written inside the function (e.g. for self-referential generators), meaning the fake read introduces aliasing conflicts with those other accesses.
For `&` this is already not a problem due to https://github.com/rust-lang/rust/pull/98017 which removed the `dereferenceable` attribute for other reasons.
Regular `&mut Unpin` references are unaffected, so I hope the impact of this is going to be tiny.
The first commit does some refactoring of the `PointerKind` enum since I found the old code very confusing each time I had to touch it. It doesn't change behavior.
EDIT: Turns out our `Box<!Unpin>` treatment was incorrect, too, so the PR also fixes that now (in codegen and Miri): we do not put `noalias` on these boxes any more.
bors [Tue, 7 Feb 2023 00:03:02 +0000 (00:03 +0000)]
Auto merge of #107693 - petrochenkov:metable, r=oli-obk
rustc_metadata: Encode/decode some `LazyArrays` without an `Option`
and a couple of related changes, see individual commits.
Addresses comments in https://github.com/rust-lang/rust/pull/107166#discussion_r1083417124 and https://github.com/rust-lang/rust/pull/107166#discussion_r1083768417, cc `@cjgillot` `@oli-obk.`
bors [Mon, 6 Feb 2023 20:20:53 +0000 (20:20 +0000)]
Auto merge of #107738 - matthiaskrgr:rollup-o18lzi8, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #106477 (Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples)
- #107596 (Add nicer output to PGO build timer)
- #107692 (Sort Generator `print-type-sizes` according to their yield points)
- #107714 (Clarify wording on f64::round() and f32::round())
- #107720 (end entry paragraph with a period (.))
- #107724 (remove unused rustc_* imports)
- #107725 (Turn MarkdownWithToc into a struct with named fields)
- #107731 (interpret: move discriminant reading and writing to separate file)
- #107735 (Add mailmap for commits made by xes@meta.com)
Matthias Krüger [Mon, 6 Feb 2023 20:16:43 +0000 (21:16 +0100)]
Rollup merge of #107731 - RalfJung:interpret-discriminant, r=cjgillot
interpret: move discriminant reading and writing to separate file
This is quite different from the otherwise fairly general read and write functions in place.rs and operand.rs, and also it's nice to have these two functions close together as they are basically inverses of each other.
Matthias Krüger [Mon, 6 Feb 2023 20:16:41 +0000 (21:16 +0100)]
Rollup merge of #107692 - Swatinem:printsizeyield, r=compiler-errors
Sort Generator `print-type-sizes` according to their yield points
Especially when trying to diagnose runaway future sizes, it might be more intuitive to sort the variants according to the control flow (aka their yield points) rather than the size of the variants.
Matthias Krüger [Mon, 6 Feb 2023 20:16:40 +0000 (21:16 +0100)]
Rollup merge of #107596 - Kobzol:stage-build-timer, r=Mark-Simulacrum
Add nicer output to PGO build timer
This PR modifies the timer used in the PGO build script to contain nicer, hierarchical output of the individual build steps. It's not trivial to test locally, so I'll fire up a dist build right away.
Matthias Krüger [Mon, 6 Feb 2023 20:16:39 +0000 (21:16 +0100)]
Rollup merge of #106477 - Nathan-Fenner:nathanf/refined-error-span-trait-impl, r=compiler-errors
Refine error spans for "The trait bound `T: Trait` is not satisfied" when passing literal structs/tuples
This PR adds a new heuristic which refines the error span reported for "`T: Trait` is not satisfied" errors, by "drilling down" into individual fields of structs/enums/tuples to point to the "problematic" value.
Here's a self-contained example of the difference in error span:
```rs
struct Burrito<Filling> {
filling: Filling,
}
impl <Filling: Delicious> Delicious for Burrito<Filling> {}
fn eat_delicious_food<Food: Delicious>(food: Food) {}
fn will_type_error() {
eat_delicious_food(Burrito { filling: Kale });
// ^~~~~~~~~~~~~~~~~~~~~~~~~ (before) The trait bound `Kale: Delicious` is not satisfied
// ^~~~ (after) The trait bound `Kale: Delicious` is not satisfied
}
```
(kale is fine, this is just a silly food-based example)
Before this PR, the error span is identified as the entire argument to the generic function `eat_delicious_food`. However, since only `Kale` is the "problematic" part, we can point at it specifically. In particular, the primary error message itself mentions the missing `Kale: Delicious` trait bound, so it's much clearer if this part is called out explicitly.
---
The _existing_ heuristic tries to label the right function argument in `point_at_arg_if_possible`. It goes something like this:
- Look at the broken base trait `Food: Delicious` and find which generics it mentions (in this case, only `Food`)
- Look at the parameter type definitions and find which of them mention `Filling` (in this case, only `food`)
- If there is exactly one relevant parameter, label the corresponding argument with the error span, instead of the entire call
This PR extends this heuristic by further refining the resulting expression span in the new `point_at_specific_expr_if_possible` function. For each `impl` in the (broken) chain, we apply the following strategy:
The strategy to determine this span involves connecting information about our generic `impl`
with information about our (struct) type and the (struct) literal expression:
- Find the `impl` (`impl <Filling: Delicious> Delicious for Burrito<Filling>`)
that links our obligation (`Kale: Delicious`) with the parent obligation (`Burrito<Kale>: Delicious`)
- Find the "original" predicate constraint in the impl (`Filling: Delicious`) which produced our obligation.
- Find all of the generics that are mentioned in the predicate (`Filling`).
- Examine the `Self` type in the `impl`, and see which of its type argument(s) mention any of those generics.
- Examing the definition for the `Self` type, and identify (for each of its variants) if there's a unique field
which uses those generic arguments.
- If there is a unique field mentioning the "blameable" arguments, use that field for the error span.
Before we do any of this logic, we recursively call `point_at_specific_expr_if_possible` on the parent
obligation. Hence we refine the `expr` "outwards-in" and bail at the first kind of expression/impl we don't recognize.
This function returns a `Result<&Expr, &Expr>` - either way, it returns the `Expr` whose span should be
reported as an error. If it is `Ok`, then it means it refined successfull. If it is `Err`, then it may be
only a partial success - but it cannot be refined even further.
---
I added a new test file which exercises this new behavior. A few existing tests were affected, since their error spans are now different. In one case, this leads to a different code suggestion for the autofix - although the new suggestion isn't _wrong_, it is different from what used to be.
This change doesn't create any new errors or remove any existing ones, it just adjusts the spans where they're presented.
---
Some considerations: right now, this check occurs in addition to some similar logic in `adjust_fulfillment_error_for_expr_obligation` function, which tidies up various kinds of error spans (not just trait-fulfillment error). It's possible that this new code would be better integrated into that function (or another one) - but I haven't looked into this yet.
Although this code only occurs when there's a type error, it's definitely not as efficient as possible. In particular, there are definitely some cases where it degrades to quadratic performance (e.g. for a trait `impl` with 100+ generic parameters or 100 levels deep nesting of generic types). I'm not sure if these are realistic enough to worry about optimizing yet.
There's also still a lot of repetition in some of the logic, where the behavior for different types (namely, `struct` vs `enum` variant) is _similar_ but not the same.
---
I think the biggest win here is better targeting for tuples; in particular, if you're using tuples + traits to express variadic-like functions, the compiler can't tell you which part of a tuple has the wrong type, since the span will cover the entire argument. This change allows the individual field in the tuple to be highlighted, as in this example:
```
// NEW
LL | want(Wrapper { value: (3, q) });
| ---- ^ the trait `T3` is not implemented for `Q`
// OLD
LL | want(Wrapper { value: (3, q) });
| ---- ^~~~~~~~~~~~~~~~~~~~~~~~~ the trait `T3` is not implemented for `Q`
```
Especially with large tuples, the existing error spans are not very effective at quickly narrowing down the source of the problem.
bors [Mon, 6 Feb 2023 16:28:18 +0000 (16:28 +0000)]
Auto merge of #107727 - Dylan-DPC:rollup-b1yexcl, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #107553 (Suggest std::ptr::null if literal 0 is given to a raw pointer function argument)
- #107580 (Recover from lifetimes with default lifetimes in generic args)
- #107669 (rustdoc: combine duplicate rules in ayu CSS)
- #107685 (Suggest adding a return type for async functions)
- #107687 (Adapt SROA MIR opt for aggregated MIR)
Dylan DPC [Mon, 6 Feb 2023 14:24:13 +0000 (19:54 +0530)]
Rollup merge of #107553 - edward-shen:edward-shen/suggest-null-ptr, r=WaffleLapkin
Suggest std::ptr::null if literal 0 is given to a raw pointer function argument
Implementation feels a little sus (we're parsing the span for a `0`) but it seems to fall in line the string-expected-found-char condition right above this check, so I think it's fine.
Feedback appreciated on help text? I think it's consistent but it does sound a little awkward maybe?
Ralf Jung [Tue, 27 Dec 2022 11:31:17 +0000 (12:31 +0100)]
make PointerKind directly reflect pointer types
The code that consumes PointerKind (`adjust_for_rust_scalar` in rustc_ty_utils)
ended up using PointerKind variants to talk about Rust reference types (& and
&mut) anyway, making the old code structure quite confusing: one always had to
keep in mind which PointerKind corresponds to which type. So this changes
PointerKind to directly reflect the type.
The heuristic is pretty close to the name resolver, maxLevDistance = `Math.floor(queryLen / 3)`.
Fixes #103357
Fixes #82131
Similar to https://github.com/rust-lang/rust/pull/103710, but following the suggestion in https://github.com/rust-lang/rust/pull/103710#issuecomment-1296360267 to use `floor` instead of `ceil`, and unblocked now that https://github.com/rust-lang/rust/pull/105796 made it so that setting the max lev distance to `0` doesn't cause substring matches to be removed.
Joshua Nelson [Sun, 5 Feb 2023 20:43:26 +0000 (14:43 -0600)]
Run `expand-yaml-anchors` in `x test tidy`
Previously, the pre-commit hook which runs `x test tidy` could pass only to have CI fail within the first 30 seconds.
This adds about 30 seconds to `test tidy` (for an initial run, much less after the tool is built the first time)
in exchange for catching errors in `.github/workflows/ci.yml` before they're pushed.
bors [Sun, 5 Feb 2023 17:32:26 +0000 (17:32 +0000)]
Auto merge of #107663 - matthiaskrgr:107423-point-at-EOF-code, r=compiler-errors
don't point at nonexisting code beyond EOF when warning about delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
Arpad Borsos [Sun, 5 Feb 2023 15:26:51 +0000 (16:26 +0100)]
Sort Generator `print-type-sizes` according to their yield points
Especially when trying to diagnose runaway future sizes, it might be
more intuitive to sort the variants according to the control flow
(aka their yield points) rather than the size of the variants.
Change wording from "nullable" to "default".
Introduce a trait `IsDefault` for detecting values that are encoded as zeros or not encoded at all.
Add panics to impossible cases.
Some other minor cleanups.
bors [Sun, 5 Feb 2023 11:10:11 +0000 (11:10 +0000)]
Auto merge of #107679 - est31:less_import_overhead, r=compiler-errors
Less import overhead for errors
This removes huge (3+ lines) import lists found in files that had their error reporting migrated. These lists are bad for developer workflows as adding, removing, or editing a single error's name might cause a chain reaction that bloats the git diff. As the error struct names are long, the likelihood of such chain reactions is high.
Follows the suggestion by `@Nilstrieb` in the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/massive.20use.20statements) to replace the `use errors::{FooErr, BarErr};` with `use errors;` and then changing to `errors::FooErr` on the usage sites.
I have used sed to do most of the changes, i.e. something like:
```
sed -i -E 's/(create_err|create_feature_err|emit_err|create_note|emit_fatal|emit_warning)\(([[:alnum:]]+|[A-Z][[:alnum:]:]*)( \{|\))/\1(errors::\2\3/' path/to/file.rs
```
& then I manually fixed the errors that occured. Most manual changes were required in `compiler/rustc_parse/src/parser/expr.rs`.
bors [Sun, 5 Feb 2023 07:36:37 +0000 (07:36 +0000)]
Auto merge of #107434 - BoxyUwU:nll_const_equate, r=compiler-errors
emit `ConstEquate` in `TypeRelating<D>`
emitting `ConstEquate` during mir typeck is useful since it can help catch bugs in hir typeck incase our impl of `ConstEquate` is wrong.
doing this did actually catch a bug, when relating `Expr::Call` we `==` the types of all the argument consts which spuriously returns false if the type contains const projections/aliases which causes us to fall through to the `expected_found` error arm.
Generally its an ICE if the `Const`'s `Ty`s arent equal but `ConstKind::Expr` is kind of special since they are sort of like const items that are `const CALL<F: const Fn(...), const N: F>` though we dont actually explicitly represent the `F` type param explicitly in `Expr::Call` so I just made us relate the `Const`'s ty field to avoid getting ICEs from the tests I added and the following existing test:
```rust
// tests/ui/const-generics/generic_const_exprs/different-fn.rs
#![feature(generic_const_exprs)]
#![allow(incomplete_features)]
use std::mem::size_of;
use std::marker::PhantomData;
fn main() {
test::<u32>();
}
```
which has us relate two `ConstKind::Value` one for the fn item of `size_of::<Foo<T>>` and one for the fn item of `size_of::<T>()`, these only differ by their `Ty` and if we don't relate the `Ty` we'll end up getting an ICE from the checks that ensure the `ty` fields always match.
In theory `Expr::UnOp` has the same problem so I added a call to `relate` for the ty's, although I was unable to create a repro test.
bors [Sat, 4 Feb 2023 21:07:10 +0000 (21:07 +0000)]
Auto merge of #107672 - matthiaskrgr:rollup-7e6dbuk, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #107116 (consolidate bootstrap docs)
- #107646 (Provide structured suggestion for binding needing type on E0594)
- #107661 (Remove Esteban from review queues for a while)
bors [Sat, 4 Feb 2023 18:11:02 +0000 (18:11 +0000)]
Auto merge of #107549 - Zoxc:rustc-shared, r=jyn514
Move code in `rustc_driver` out to a new `rustc_driver_impl` crate to allow pipelining
That adds a `rustc_shared` library which contains all the rustc library crates in a single dylib. It takes over this role from `rustc_driver`. This is done so that `rustc_driver` can be compiled in parallel with other crates. `rustc_shared` is intentionally left empty so it only does linking.
An alternative could be to move the code currently in `rustc_driver` into a new crate to avoid changing the name of the distributed library.
Matthias Krüger [Sat, 4 Feb 2023 12:27:53 +0000 (13:27 +0100)]
don't point at nonexisting code beyond EOF when warning about unused delims
Previously we would show this:
```
warning: unnecessary braces around block return value
--> /tmp/bad.rs:1:8
|
1 | fn a(){{{
| ^ ^
|
= note: `#[warn(unused_braces)]` on by default
help: remove these braces
|
1 - fn a(){{{
1 + fn a(){{
|
```
which is now hidden in this case.
We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing.
This would cause the debug assertion ice to trigger.
I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :(
But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable.
bors [Sat, 4 Feb 2023 03:41:57 +0000 (03:41 +0000)]
Auto merge of #107591 - krasimirgg:llvm-17-pgoopts, r=cuviper
llvm-wrapper: adapt for LLVM API changes
Adapts the wrapper for https://github.com/llvm/llvm-project/commit/516e301752560311d2cd8c2b549493eb0f98d01b, where the constructor of PGOOptions gained a new FileSystem argument. Adapted to use the real file system, similarly to the changes inside of LLVM:
https://github.com/llvm/llvm-project/commit/516e301752560311d2cd8c2b549493eb0f98d01b#diff-f409934ba27ad86494f3012324e9a3995b56e0743609ded7a387ba62bbf5edb0R236
Found via our experimental Rust + LLVM at HEAD bot: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/16853#01860e2e-5eba-4f07-8359-0325913ff410/219-517
bors [Fri, 3 Feb 2023 22:37:53 +0000 (22:37 +0000)]
Auto merge of #107650 - compiler-errors:rollup-4pntchf, r=compiler-errors
Rollup of 8 pull requests
Successful merges:
- #106887 (Make const/fn return params more suggestable)
- #107519 (Add type alias for raw OS errors)
- #107551 ( Replace `ConstFnMutClosure` with const closures )
- #107595 (Retry opening proc-macro DLLs a few times on Windows.)
- #107615 (Replace nbsp in all rustdoc code blocks)
- #107621 (Intern external constraints in new solver)
- #107631 (loudly tell people when they change `Cargo.lock`)
- #107632 (Clarifying that .map() returns None if None.)
Michael Goulet [Fri, 3 Feb 2023 22:15:24 +0000 (14:15 -0800)]
Rollup merge of #107631 - BoxyUwU:triagebot_cargo_lock, r=compiler-errors
loudly tell people when they change `Cargo.lock`
It keeps happening that people accidentally commit changes to `Cargo.lock` and then have to be told by a reviewer to undo this. I've also seen cases where PRs are merged that accidentally changed `Cargo.lock` during a rebase.. I figure that purposeful changes to `Cargo.lock` are likely rarer than these accidental ones?
Michael Goulet [Fri, 3 Feb 2023 22:15:22 +0000 (14:15 -0800)]
Rollup merge of #107595 - michaelwoerister:retry_proc_macro_loading, r=petrochenkov
Retry opening proc-macro DLLs a few times on Windows.
On Windows, the compiler [sometimes](https://users.rust-lang.org/t/error-loadlibraryexw-failed/77603) fails with the message `error: LoadLibraryExW failed` when trying to load a proc-macro crate. The error seems to occur intermittently, similar to https://github.com/rust-lang/rust/issues/86929, however, it seems to be almost impossible to reproduce outside of CI environments and thus very hard to debug. The fact that the error only occurs intermittently makes me think that this is a timing related issue.
This PR is an attempt to mitigate the issue by letting the compiler retry a few times when encountering this specific error (which resolved the issue described in https://github.com/rust-lang/rust/issues/86929).
Michael Goulet [Fri, 3 Feb 2023 22:15:21 +0000 (14:15 -0800)]
Rollup merge of #106887 - compiler-errors:suggest-types-more, r=oli-obk
Make const/fn return params more suggestable
Bumps const item type suggestions to MachineApplicable (fixes #106843), also replaces FnDef with FnPtr items in return type suggestions to make more things suggestable.
projects / rust.git / log