bors [Mon, 9 Jan 2023 18:20:00 +0000 (18:20 +0000)]
Auto merge of #106637 - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead
Rollup of 10 pull requests
Successful merges:
- #105292 (Change a commit_if_ok call to probe)
- #105655 (Remove invalid case for mutable borrow suggestion)
- #106047 (Fix ui constant tests for big-endian platforms)
- #106061 (Enable Shadow Call Stack for Fuchsia on AArch64)
- #106164 (Move `check_region_obligations_and_report_errors` to `TypeErrCtxt`)
- #106291 (Fix incorrect suggestion for extra `&` in pattern)
- #106389 (Simplify some canonical type alias names)
- #106468 (Use FxIndexSet when updating obligation causes in `adjust_fulfillment_errors_for_expr_obligation`)
- #106549 (Use fmt named parameters in rustc_borrowck)
- #106614 (error-code docs improvements (No. 2))
fee1-dead [Mon, 9 Jan 2023 15:35:32 +0000 (23:35 +0800)]
Rollup merge of #106614 - Ezrashaw:ui-test-fixups-2, r=GuillaumeGomez
error-code docs improvements (No. 2)
- Added empty error-code docs for `E0208`, `E0640` and `E0717` with the "internal" header as discussed on Discord.
- Wrote docs and UI test for `E0711`, again with the header.
- `tidy` changes are common-sense and make everything pass, `style.rs` hack is annoying though.
fee1-dead [Mon, 9 Jan 2023 15:35:30 +0000 (23:35 +0800)]
Rollup merge of #106389 - compiler-errors:no-canonicalized, r=lcnr
Simplify some canonical type alias names
* delete the `Canonicalized<'tcx>` type alias in favor for `Canonical<'tcx>`
* `CanonicalizedQueryResponse` -> `CanonicalQueryResponse`
I don't particularly care about the latter, but it should be consistent. We could alternatively delete the first alias and rename the struct to `Canonicalized`, and then keep the name of `CanonicalizedQueryResponse` untouched.
fee1-dead [Mon, 9 Jan 2023 15:35:27 +0000 (23:35 +0800)]
Rollup merge of #106047 - uweigand:s390x-test-bigendian-ui, r=oli-obk
Fix ui constant tests for big-endian platforms
A number of tests under ui/const-ptr and ui/consts are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the stderr test files.
Fix this by a combination of two types of changes:
- Where possible (i.e. where the particular value of a constant does not affect the purpose of the test), choose constant values that have the same encoding on big- and little-endian platforms.
- Where this is not possible, provide a normalize-stderr-test rule that transforms the printed big-endian encoding of such constants into the corresponding little-endian form.
Fixes part of https://github.com/rust-lang/rust/issues/105383.
fee1-dead [Mon, 9 Jan 2023 15:35:27 +0000 (23:35 +0800)]
Rollup merge of #105655 - RedDocMD:bug-105645, r=oli-obk
Remove invalid case for mutable borrow suggestion
If we have a call such as `foo(&mut buf)` and after reference
collapsing the type is inferred as `&T` where-as the required type is
`&mut T`, don't suggest `foo(&mut mut buf)`. This is wrong syntactically
and the issue lies elsewhere, not in the borrow.
fee1-dead [Mon, 9 Jan 2023 15:35:26 +0000 (23:35 +0800)]
Rollup merge of #105292 - JulianKnodt:no_eager_commit, r=BoxyUwU
Change a commit_if_ok call to probe
Removes an over-eager `commit_if_ok` which makes inference worse.
I'm not entirely sure whether it's ok to remove the check that types are the same, because casting seems to cause equality checks with incorrect types?
Initially, I thought I would need to enable operand propagation then do something else, but actually https://github.com/rust-lang/rust/pull/74491 already has the fix for the issue in question! It looks like this optimization was put under MIR opt level 3 due to possible soundness/stability implications, then demoted further to MIR opt level 4 when MIR opt level 2 became associated with `--release`.
Perhaps in the past we were doing CTFE on optimized MIR? We aren't anymore, so this optimization has no stability implications.
kadmin [Wed, 21 Dec 2022 21:53:52 +0000 (21:53 +0000)]
Clean up
Simplify match statement
Add multiple tests
- 1 test for checking `N + 1 + 1` does not unify with `N+1`
- 2 tests for checking that a function that uses two parameters only returns the parameter that
is actually used.
- Check exact repeat predicates
kadmin [Tue, 13 Dec 2022 09:51:13 +0000 (09:51 +0000)]
Change based on comments
Instead of just switching to a probe, check for different matches, and see how many there are.
If one, unify it, otherwise return true and let it be unified later.
bors [Mon, 9 Jan 2023 05:09:45 +0000 (05:09 +0000)]
Auto merge of #106616 - compiler-errors:rollup-emcj0o3, r=compiler-errors
Rollup of 8 pull requests
Successful merges:
- #104163 (Don't derive Debug for `OnceWith` & `RepeatWith`)
- #106131 (Mention "signature" rather than "fn pointer" when impl/trait methods are incompatible)
- #106363 (Structured suggestion for `&mut dyn Iterator` when possible)
- #106497 (Suggest using clone when we have &T and T implemented Clone)
- #106584 (Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator.)
- #106600 (Suppress type errors that come from private fields)
- #106602 (Add goml scripts to tidy checks)
- #106606 (Do not emit structured suggestion for turbofish with wrong span)
Michael Goulet [Mon, 9 Jan 2023 03:57:55 +0000 (19:57 -0800)]
Rollup merge of #106600 - compiler-errors:no-private-field-ty-err, r=estebank
Suppress type errors that come from private fields
Fixes #57320
There was some discussion here (https://github.com/rust-lang/rust/issues/57320#issuecomment-451308420), but I honestly think the second error is worth suppressing regardless.
I would be open to feedback though -- perhaps we can suppress the `.len()` suggestion if there's type error (since we have access to [`Expectation`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/enum.Expectation.html), we can determine that).
Michael Goulet [Mon, 9 Jan 2023 03:57:54 +0000 (19:57 -0800)]
Rollup merge of #106584 - kpreid:vec-allocator, r=JohnTitor
Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator.
Currently, the documentation of `Vec::from_raw_parts` and `Vec::from_raw_parts_in` says nothing about what allocator the pointer must come from. This PR adds that missing information explicitly.
Michael Goulet [Mon, 9 Jan 2023 03:57:52 +0000 (19:57 -0800)]
Rollup merge of #104163 - H4x5:once-repeat-with-debug, r=dtolnay
Don't derive Debug for `OnceWith` & `RepeatWith`
Closures don't impl Debug, so the derived impl is kinda useless. The behavior of not debug-printing closures is consistent with the rest of the iterator adapters/sources.
bors [Sun, 8 Jan 2023 22:40:38 +0000 (22:40 +0000)]
Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnay
Loosen the bound on the Debug implementation of Weak.
Both `rc::Weak<T>` and `sync::Weak<T>` currently require `T: Debug` in their own `Debug` implementations, but they don't currently use it; they only ever print a fixed string.
A general implementation of Debug for Weak that actually attempts to upgrade and rely on the contents is unlikely in the future because it may have unbounded recursion in the presence of reference cycles, which Weak is commonly used in. (This was the justification for why the current implementation [was implemented the way it is](https://github.com/rust-lang/rust/pull/19388/commits/f0976e2cf3f6b0027f118b791e0888b29fbb41a7)).
When I brought it up [on the forum](https://internals.rust-lang.org/t/could-the-bound-on-weak-debug-be-relaxed/15504), it was suggested that, even if an implementation is specialized in the future that relies on the data stored within the Weak, it would likely rely on specialization anyway, and could therefore easily specialize on the Debug bound as well.
bors [Sun, 8 Jan 2023 17:49:31 +0000 (17:49 +0000)]
Auto merge of #106449 - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum
Add retry mechanism for rustdoc GUI tests to reduce flakyness
Part of #93784.
I added 3 retries for failing GUI tests. An important note: if more than half of total tests fail, I don't retry because it's very likely not flakyness anymore at this point but a missing update after changes.
bors [Sun, 8 Jan 2023 14:40:52 +0000 (14:40 +0000)]
Auto merge of #106235 - compiler-errors:rework-bounds-collection, r=davidtwco
Rework `Bounds` collection
I think it's weird for the `Bounds` struct in astconv to store its predicates *almost* converted into real predicates... so we do this eagerly, instead of lazily.
Yuki Okushi [Sun, 8 Jan 2023 08:01:49 +0000 (17:01 +0900)]
Rollup merge of #106580 - Ezrashaw:remove-e0313, r=compiler-errors
remove unreachable error code `E0313`
Fixes #103742
Makes #103433 redundant
Implements removal of `E0313`. I agree with the linked issue that this error code is unreachable but if someone could confirm that would be great, are crater runs done for this sort of thing?
Also removed a redundant `// ignore-tidy-filelength` that I found while reading code.
Yuki Okushi [Sun, 8 Jan 2023 08:01:48 +0000 (17:01 +0900)]
Rollup merge of #106557 - Ezrashaw:ui-test-fixups-1, r=GuillaumeGomez
Add some UI tests and reword error-code docs
Added UI tests for `E0013` and `E0015`. Error code docs for `E0015` were a bit unclear (they referred to all non-const errors in const context, when only non-const functions applied), so I touched them up a bit.
I also fixed up some issues in the new `error_codes.rs` tidy check (linked #106341), that I overlooked previously.
Yuki Okushi [Sun, 8 Jan 2023 08:01:46 +0000 (17:01 +0900)]
Rollup merge of #106410 - clubby789:borrow-mut-self-mut-self-diag, r=compiler-errors
Suggest `mut self: &mut Self` for `?Sized` impls
Closes #106325
Closes #93078
The suggestion is _probably_ not what the user wants (hence `MaybeIncorrect`) but at least makes the problem in the above issues clearer. It might be better to add a note explaining why this is the case, but I'm not sure how best to word that so this is a start.
bors [Sun, 8 Jan 2023 01:34:05 +0000 (01:34 +0000)]
Auto merge of #104658 - thomcc:rand-update-and-usable-no_std, r=Mark-Simulacrum
Update `rand` in the stdlib tests, and remove the `getrandom` feature from it.
The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` support. Currently those targets can only run the subset of stdlib tests that exist in uitests, and (generally speaking), we prefer not to test libstd functionality in uitests, which came up recently in https://github.com/rust-lang/rust/pull/104095 and https://github.com/rust-lang/rust/pull/104185. Additionally, the fact that we can't update `rand`/`getrandom` means we're stuck with the old set of tier3 targets, so can't test new ones.
~~Anyway, I haven't checked that this actually does allow use on tier3 targets (I think it does not, as some work is needed in stdlib submodules) but it moves us slightly closer to this, and seems to allow at least finally updating our `rand` dep, which definitely improves the status quo.~~ Checked and works now.
For the most part, our tests and benchmarks are fine using hard-coded seeds. A couple tests seem to fail with this (stuff manipulating the environment expecting no collisions, for example), or become pointless (all inputs to a function become equivalent). In these cases I've done a (gross) dance (ab)using `RandomState` and `Location::caller()` for some extra "entropy".
Trying to share that code seems *way* more painful than it's worth given that the duplication is a 7-line function, even if the lines are quite gross. (Keeping in mind that sharing it would require adding `rand` as a non-dev dep to std, and exposing a type from it publicly, all of which sounds truly awful, even if done behind a perma-unstable feature).
See also some previous attempts:
- https://github.com/rust-lang/rust/pull/86963 (in particular https://github.com/rust-lang/rust/pull/86963#issuecomment-885438936 which explains why this is non-trivial)
- https://github.com/rust-lang/rust/pull/89131
- https://github.com/rust-lang/rust/pull/96626#issuecomment-1114562857 (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal).
- https://github.com/rust-lang/rust/pull/104185
- Probably more. It's very tempting of a thing to "just update".
Matthias Krüger [Sat, 7 Jan 2023 19:43:23 +0000 (20:43 +0100)]
Rollup merge of #106556 - notriddle:notriddle/margin-left-content-mobile, r=GuillaumeGomez
rustdoc: remove no-op mobile CSS `.content { margin-left: 0 }`
This rule was added to override non-zero left margin on `.content`, which was removed in 135281ed1525db15edd8ebd092aa10aa40df2386 and the margin-left was put on the docblock.
Matthias Krüger [Sat, 7 Jan 2023 19:43:21 +0000 (20:43 +0100)]
Rollup merge of #105859 - compiler-errors:hr-lifetime-add, r=davidtwco
Point out span where we could introduce higher-ranked lifetime
Somewhat addresses #105422, but not really. We don't have that much useful information here since we're still in resolution :^(
Maybe this suggestion isn't worth it. If the reviewer has an idea how we can get a more succinct binder information for a structured suggestion, it would be appreciated.
Matthias Krüger [Sat, 7 Jan 2023 19:43:20 +0000 (20:43 +0100)]
Rollup merge of #105517 - pcc:process-panic-after-fork, r=davidtwco
Fix process-panic-after-fork.rs to pass on newer versions of Android.
The test process-panic-after-fork.rs was checking that abort() resulted in SIGSEGV on Android. This non-standard behavior was fixed back in 2013, so let's fix the test to also accept the standard behavior on Android.
Matthias Krüger [Sat, 7 Jan 2023 19:43:19 +0000 (20:43 +0100)]
Rollup merge of #104543 - JhonnyBillM:migrate-codegen-ssa-to-diagnostics-structs-pt3, r=davidtwco
Migrate `codegen_ssa` to diagnostics structs - [Part 3]
Completes migrating `codegen_ssa` module except 2 outstanding errors that depend on other crates:
1. [`rustc_middle::mir::interpret::InterpError`](https://github.com/rust-lang/rust/blob/b6097f2e1b2ca62e188ba53cf43bd66b06b36915/compiler/rustc_middle/src/mir/interpret/error.rs#L475): I saw `rustc_middle` is unassigned, I am open to take this work.
2. `codegen_llvm`'s use of `fn span_invalid_monomorphization_error`, which I started to replace in the [last commit](https://github.com/rust-lang/rust/commit/9a31b3cdda78a2c0891828254fe9886e0a1cfd16) of this PR, but would like to know the team's preference on how we should keep replacing the other macros:
2.1. Update macros to expect a `Diagnostic`
2.2. Remove macros and expand the code on each use.
See [some examples of the different options in this experimental commit](https://github.com/JhonnyBillM/rust/commit/64aee83e80857dcfa450f0c6e31d5f29c6d577e6)
Matthias Krüger [Sat, 7 Jan 2023 19:43:18 +0000 (20:43 +0100)]
Rollup merge of #101936 - IntQuant:issue-100717-infer-4, r=compiler-errors
Migrating rustc_infer to session diagnostics (part 3)
``@rustbot`` label +A-translation
r? rust-lang/diagnostics
cc https://github.com/rust-lang/rust/issues/100717
Seems like a part of static_impl_trait.rs emits suggestions in a loop, and note.rs needs to have two instances of the same subdiagnostic, so these will need to wait until we have eager translation/list support.
Other than that, there is only error_reporting/mod.rs left to migrate.
Projection types in user annotations may contain inference variables.
This makes the normalization depend on the unification with the actual
type and thus requires a separate TypeOp to track the obligations.
Otherwise simply calling `TypeChecker::normalize` would ICE with
"unexpected ambiguity"
We delay projection normalization to further stages in order to
register user type annotations before normalization in HIR typeck.
There are two consumers of astconv: ItemCtxt and FnCtxt.
The former already expects unnormalized types from astconv, see its
AstConv trait impl.
The latter needs `RawTy` for a cleaner interface.
Unfortunately astconv still needs the normalization machinery in
order to resolve enum variants that have projections in the self type,
e.g. `<<T as Trait>::Assoc>::StructVariant {}`.
This is why `AstConv::normalize_ty_2` is necessary.