Seems to have caused an incremental compilation bug. The root cause of the incr comp bug is somewhat unrelated but is triggered by this PR, so I don't feel comfortable with having this PR in the codebase until it can be investigated further. Fixes #99233.
Rollup merge of #99213 - davidtwco:translation-migrate-passes, r=compiler-errors
migrate some of `rustc_passes::check_attr`'s diagnostics and derive improvements
- Implements `IntoDiagnosticArg` for `char` using its `Debug` implementation and introduces a macro for those types which just delegate the implementation to `ToString`.
- Apply the `#[rustc_lint_diagnostics]` attribute to `LintDiagnosticBuilder::build` so that diagnostic migration lints will trigger for it - some diagnostics in `rustc_privacy` need updated after this since the lints apply to that crate.
- Add support for `MultiSpan` with any of the attributes that work on a `Span` in the diagnostic derive (`SessionDiagnostic` + `LintDiagnostic`). Requires that diagnostic logic generated for these attributes are emitted in the by-move block rather than the by-ref block that they would normally have been generated in.
- Both diagnostic and subdiagnostic derives were missing the ability to add warnings to diagnostics - this is made more difficult by the `warn` attribute already existing, so this name being unavailable for the derives to use. `#[warn_]` is used instead, which requires special-casing so that `{span_,}warn` is called instead of `{span_,}warn_`.
- Migrate half of the `rustc_passes::check_attr` diagnostics to using diagnostic derives and being translatable. I got tired after a while. I modified some diagnostic output for consistency while doing this, nothing too crazy.
Rollup merge of #98582 - oli-obk:unconstrained_opaque_type, r=estebank
Allow destructuring opaque types in their defining scopes
fixes #96572
Before this PR, the following code snippet failed with an incomprehensible error, and similar code just ICEd in mir borrowck.
```rust
type T = impl Copy;
let foo: T = (1u32, 2u32);
let (a, b) = foo;
```
The problem was that the last line created MIR projections of the form `foo.0` and `foo.1`, but `foo`'s type is `T`, which doesn't have fields (only its hidden type does). But the pattern supplies enough type information (a tuple of two different inference types) to bind a hidden type.
Auto merge of #99315 - JohnTitor:rollup-77wzoc1, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #98387 (Add new unstable API `downcast` to `std::io::Error`)
- #98662 (Add std::fs::write documentation precision)
- #99253 (Remove FIXME from MIR `always_storage_live_locals`)
- #99264 (Fix typo in mod.rs)
- #99270 (Add `#[must_use]` to `Box::from_raw`)
- #99277 (Stabilize `core::ffi::CStr`, `alloc::ffi::CString`, and friends)
- #99307 (Add regression test for #64401)
does not account for when both `width` and `precision` are both `Count::CountIsName`, so split the check for these two fields into two separate `if let`.
Also, remove any future potential for ICEs by removing the index operator altogether.
---
It is still suspicious that this indexing was broken and caused the ICE, as opposed to just causing a spurious lint message.
cc `@PrestonFrom,` who may be familiar with this code because of implementing the lint this touches, perhaps you'd like to look into why named arguments in `FormatSpec.precision` seem to have indices that don't correspond to a span in `Context.arg_spans`?
Edit: Opened #99265 to track a (related?) incorrect argument indexing issue.
Auto merge of #96482 - willcrichton:fix-trait-suggestion-for-binops, r=estebank
Add Output = expected type trait obligation for known binary operators
This PR is a follow-on to #94034 that addresses #96442. That is, after replacing the trait-suggestion logic in `op.rs` with a more generic path that analyzes a general set of `Obligation`s, then we lost some specificity in the suggestions where the bounds on the associated type `Output=` would not get suggested.
This PR fixes this issue by changing `FnCtxt::construct_obligation_for_trait` to include a new `ProjectionPredicate` obligation for binary operators that obliges that `Output` is the same as the expected type of the expression. Additionally, to get the expected type of the expression, this PR threads the `Expectation<'tcx>` structure throughout several functions.
See src/test/ui/generic-associated-types/missing-bounds.stderr for an example of how this works.
One side effect of this change is it causes type-check failures with binops to include additional information. Specifically, many now say
```
error: type mismatch resolving `<Lhs as TheBinop>::Output == ExpectedTy`
```
It's up for discussion whether this added context is worth it to the user.
Auto merge of #95685 - oxidecomputer:restore-static-dwarf, r=pnkfelix
Revert "Work around invalid DWARF bugs for fat LTO"
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See #90357 for more info
and a repro case.
This commit is a mechanical revert of d5de680e20def848751cb3c11e1182408112b1d3 from PR #89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)
I have locally verified that this fixes #90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
We check that there's a single level of block nesting to ensure always
correct suggestions. If we don't, then we only provide a free-form
message to avoid misleading users in cases like
`src/test/ui/nll/borrowed-temporary-error.rs`.
We could expand the analysis to suggest hoising all of the relevant
parts of the users' code to make the code compile, but that could be
too much.
Auto merge of #99015 - lcnr:fn-ctxt-no-more, r=compiler-errors
stop using `FnCtxt` outside of hir typeck
the requirements between **hir typeck**™, and **not hir typeck**™ are different enough to warrant a full split. with this PR `FnCtxt` is now only used for hir typeck (and for one clippy lint which seems to be emulating hir typeck).
Once this PR has landed I intend to move `FnCtxt` into a new crate. This should also allow some further general improvements here.
David Wood [Mon, 11 Jul 2022 17:46:24 +0000 (18:46 +0100)]
macros: support adding warnings to diags
Both diagnostic and subdiagnostic derives were missing the ability to
add warnings to diagnostics - this is made more difficult by the `warn`
attribute already existing, so this name being unavailable for the
derives to use. `#[warn_]` is used instead, which requires
special-casing so that `{span_,}warn` is called instead of
`{span_,}warn_`.
David Wood [Mon, 11 Jul 2022 16:15:31 +0000 (17:15 +0100)]
macros: support `MultiSpan` in diag derives
Add support for `MultiSpan` with any of the attributes that work on a
`Span` - requires that diagnostic logic generated for these attributes
are emitted in the by-move block rather than the by-ref block that they
would normally have been generated in.
David Wood [Mon, 11 Jul 2022 15:28:38 +0000 (16:28 +0100)]
errors: impl `IntoDiagnosticArg` for `char`
Implements `IntoDiagnosticArg` for `char` using its `Debug`
implementation and introduces a macro for those types which just
delegate the implementation to `ToString`.
Auto merge of #99278 - Dylan-DPC:rollup-fcln6st, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #88991 (Add Nintendo Switch as tier 3 target)
- #98869 (Remove some usages of `guess_head_span`)
- #99119 (Refactor: remove a string matching about methods)
- #99209 (Correctly handle crate level page on docs.rs as well)
- #99246 (Update RLS)
Rollup merge of #99209 - GuillaumeGomez:crate-level-sidebar, r=jsha
Correctly handle crate level page on docs.rs as well
Fixes #99121.
On docs.rs, they move the `class` attribute into a child which still has `rustdoc`. So instead of using the `<body>`, we can simply use this one directly.
This is the first step towards working on incrementally adding support for the Nintendo Switch. After this lands `@leo60228` and I will work on ensuring further work is cleared from a legal perspective before continuing on to work on an allocator and porting libstd.
The plan is to keep these changes small and incremental enough so as to not cause unneeded burden on reviewers by submitting a single large patch, as was felt to be the case last attempt at upstreaming (#74567).
All this specific patch does is add the target itself without and std support, which has been tested on-device and is working as expected.
Auto merge of #99013 - RalfJung:dont-poison-my-places, r=oli-obk
interpret: get rid of MemPlaceMeta::Poison
This is achieved by refactoring the projection code (`{mplace,place,operand}_{downcast,field,index,...}`) so that we no longer need to call `assert_mem_place` in the operand handling.
Auto merge of #99267 - Dylan-DPC:rollup-d8l7y1o, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #99113 (Simplify [a]rc code a little)
- #99131 (Add label for generic arg (+ APIT) and RPIT callables in `label_fn_like`)
- #99237 (removed unused CSS and unused HTML IDs)
- #99239 (Add myself to the set of people notified when MIR changes.)
- #99241 (Remove comment referring to constness.rs)
- #99257 (Add regression test for #89436)
Rollup merge of #99257 - Manishearth:regression, r=jackh726
Add regression test for #89436
I never got around to adding such a test.
In general I think the `yoke` crate has a bunch of interesting testcases that exercise various edges of the algorithms here, it would be nice if we could simply depend on the crate and add some tests that exercise it, but I don't think that's possible. Do you or `@eddyb` think there's any use trying to upstream a bunch of common yoke minimal working example code to the testsuite and having a ton of yoke tests?
Auto merge of #96544 - m-ysk:feature/issue-96358, r=cjgillot
Stop keeping metadata in memory before writing it to disk
Fixes #96358
I created this PR according with the instruction given in the issue except for the following points:
- While the issue says "Write metadata into the temporary file in `encode_and_write_metadata` even if `!need_metadata_file`", I could not do that. That is because though I tried to do that and run `x.py test`, I got a lot of test failures as follows.