bors [Sun, 27 Feb 2022 07:02:46 +0000 (07:02 +0000)]
Auto merge of #94144 - est31:let_else_trait_selection, r=cjgillot
rustc_trait_selection: adopt let else in more places
Continuation of #89933, #91018, #91481, #93046, #93590, #94011.
I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This PR handles rustc_trait_selection.
bors [Sun, 27 Feb 2022 04:08:50 +0000 (04:08 +0000)]
Auto merge of #94361 - nikic:s390x-update, r=Mark-Simulacrum
Update dist-s390x-dist image
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've upgraded the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
Nikita Popov [Fri, 25 Feb 2022 13:31:12 +0000 (14:31 +0100)]
Update dist-s390x-dist image
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've updated the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
bors [Sat, 26 Feb 2022 21:53:03 +0000 (21:53 +0000)]
Auto merge of #93516 - nagisa:branch-protection, r=cjgillot
No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.
This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.
Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
bors [Sat, 26 Feb 2022 19:25:04 +0000 (19:25 +0000)]
Auto merge of #93449 - JakobDegen:restrict-hasdrop-optimization, r=cjgillot
Restrict query recursion in `needs_significant_drop`
Overly aggressive use of the query system to improve caching lead to query cycles and consequently ICEs. This patch fixes this by restricting the use of the query system as a cache to those cases where it is definitely correct.
Closes #92725 .
This is essentially a revert of #90845 for the significant drop case only. The general `needs_drop` still does the same thing. The hope is that this is enough to preserve the performance improvements of that PR while fixing the ICE. Should get a perf run to verify that this is the case.
bors [Sat, 26 Feb 2022 14:23:27 +0000 (14:23 +0000)]
Auto merge of #94376 - c410-f3r:more-let-chains, r=petrochenkov
Initiate the inner usage of `let_chains`
The intention here is create a strong and robust foundation for a possible future stabilization so please, do not let the lack of any external tool support prevent the merge of this PR. Besides, `let_chains` is useful by itself.
bors [Sat, 26 Feb 2022 09:41:19 +0000 (09:41 +0000)]
Auto merge of #94127 - erikdesjardins:debugattr, r=nikic
At opt-level=0, apply only ABI-affecting attributes to functions
This should provide a small perf improvement for debug builds,
and should more than cancel out the perf regression from adding noundef (https://github.com/rust-lang/rust/pull/93670#issuecomment-1038347581, #94106).
bors [Sat, 26 Feb 2022 07:00:33 +0000 (07:00 +0000)]
Auto merge of #94392 - matthiaskrgr:rollup-npscf95, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #93400 (Do not suggest using a const parameter when there are bounds on an unused type parameter)
- #93982 (Provide extra note if synthetic type args are specified)
- #94087 (Remove unused `unsound_ignore_borrow_on_drop`)
- #94235 (chalk: Fix wrong debrujin index in opaque type handling.)
- #94306 (Avoid exhausting stack space in dominator compression)
Matthias Krüger [Sat, 26 Feb 2022 06:52:44 +0000 (07:52 +0100)]
Rollup merge of #94306 - Mark-Simulacrum:dom-fixups, r=jackh726
Avoid exhausting stack space in dominator compression
Doesn't add a test case -- I ended up running into this while playing with the generated example from #43578, which we could do with a run-make test (to avoid checking a large code snippet into tree), but I suspect we don't want to wait for it to compile (locally it takes ~14s -- not terrible, but doesn't seem worth it to me). In practice stack space exhaustion is difficult to test for, too, since if we set the bound too low a different call structure above us (e.g., a nearer ensure_sufficient_stack call) would let the test pass even with the old impl, most likely.
Locally it seems like this manages to perform approximately equivalently to the recursion, but will run perf to confirm.
Matthias Krüger [Sat, 26 Feb 2022 06:52:43 +0000 (07:52 +0100)]
Rollup merge of #94235 - Dirbaio:fix-chalk-opaque-debrujin, r=jackh726
chalk: Fix wrong debrujin index in opaque type handling.
A folder in opaque type lowering was substituting all opaque type references with a variable with debrujin index 0 ignoring how many binders deep we are.
This caused an ICE with `Not enough bound vars: ^0 not found in []` ([full logs](https://gist.github.com/Dirbaio/2b9374ff4fce37afb9d665dc9f0000df)) with the following code.
With the fix, it no longer ICEs. It still doesn't typecheck due to generator issues. I've added a "known-bug" test so that at least it doesn't regress back to ICEing.
bors [Sat, 26 Feb 2022 02:09:29 +0000 (02:09 +0000)]
Auto merge of #94385 - matthiaskrgr:rollup-4pwegqk, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #93603 (Populate liveness facts when calling `get_body_with_borrowck_facts` without `-Z polonius`)
- #93870 (Fix switch on discriminant detection in a presence of coverage counters)
- #94355 (Add one more case to avoid ICE)
- #94363 (Remove needless borrows from core::fmt)
- #94377 (`check_used` should only look at actual `used` attributes)
Matthias Krüger [Fri, 25 Feb 2022 23:49:20 +0000 (00:49 +0100)]
Rollup merge of #93603 - connorff:compute-polonius-liveness-facts-flag, r=ecstatic-morse
Populate liveness facts when calling `get_body_with_borrowck_facts` without `-Z polonius`
For a new feature of [Flowistry](https://github.com/willcrichton/flowistry), a static-analysis tool, we need to obtain a `mir::Body`'s liveness facts using `get_body_with_borrowck_facts` (added in #86977). We'd like to do this without passing `-Z polonius` as a compiler arg to avoid borrow checking the entire crate.
Support for doing this was added in #88983, but the Polonius input facts used for liveness analysis are empty. This happens because the liveness input facts are populated in `liveness::generate` depending only on the value of `AllFacts::enabled` (which is toggled via compiler args).
This PR propagates the [`use_polonius`](https://github.com/rust-lang/rust/blob/8b09ba6a5d5c644fe0f1c27c7f9c80b334241707/compiler/rustc_borrowck/src/nll.rs#L168) flag to `liveness::generate` to support populating liveness facts without requiring the `-Z polonius` flag.
This fix is somewhat patchy - if it'd be better to add more widely-accessible state (like `AllFacts::enabled`) I'd be open to ideas!
bors [Fri, 25 Feb 2022 20:53:48 +0000 (20:53 +0000)]
Auto merge of #94369 - matthiaskrgr:rollup-qtripm2, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #93850 (Don't ICE when an extern static is too big for the current architecture)
- #94154 (Wire up unstable rustc --check-cfg to rustdoc)
- #94353 (Fix debug_assert in unused lint pass)
- #94366 (Add missing item to release notes)
Matthias Krüger [Fri, 25 Feb 2022 19:12:48 +0000 (20:12 +0100)]
Rollup merge of #94353 - flip1995:fix_debug_assert_unused, r=Dylan-DPC
Fix debug_assert in unused lint pass
This fixes a debug assertion in the unused lint pass. As a side effect, this also improves the span generated for tuples in the `unused_must_use` lint.
found in #94329
A reproducer for this would be
```rust
fn main() { (1, (3,)); }
```
Not sure, if I should add a regression test for a `debug_assert`.
Matthias Krüger [Fri, 25 Feb 2022 19:12:47 +0000 (20:12 +0100)]
Rollup merge of #94154 - Urgau:rustdoc-check-cfg, r=GuillaumeGomez
Wire up unstable rustc --check-cfg to rustdoc
This pull-request wire up the new unstable `--check-cfg` option from `rustc` to `rustdoc` as [requested](https://github.com/rust-lang/rust/pull/93915#discussion_r807560445) in the [pull-request](https://github.com/rust-lang/rust/pull/93915) that introduce `--check-cfg`.
The motivation was describe in the original PR by ``@jyn514`` who wrote https://github.com/rust-lang/rust/pull/89346#issuecomment-930129761:
> > add plumbing to pass --check-cfg from rustdoc (do we want this one?)
>
> It would be useful, I think, it catches issues like cfg(doctst) or something (and in general I would like expansion to match rustc as closely as possible).
Matthias Krüger [Fri, 25 Feb 2022 19:12:46 +0000 (20:12 +0100)]
Rollup merge of #93850 - asquared31415:extern-static-size-ice, r=jackh726
Don't ICE when an extern static is too big for the current architecture
Fixes #93760
Emit an error instead of ICEing when an `extern` static's size overflows the allowed maximum for the target.
Changes the error message in the existing `delay_span_bug` call to the true layout error, first for debugging purposes, but opted to leave in to potentially assist future developers as it was being reached in unexpected ways already.
bors [Fri, 25 Feb 2022 16:09:56 +0000 (16:09 +0000)]
Auto merge of #94279 - tmiasko:write-print, r=Mark-Simulacrum
Print `ParamTy` and `ParamConst` instead of displaying them
Display for `ParamTy` and `ParamConst` is implemented in terms of print.
Using print avoids creating a new `FmtPrinter` just to display the
parameter name.
bors [Fri, 25 Feb 2022 13:28:49 +0000 (13:28 +0000)]
Auto merge of #94357 - matthiaskrgr:rollup-xrjaof3, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #93845 (Remove in band lifetimes)
- #94155 (Extend toggle GUI test a bit)
- #94252 (don't special case `DefKind::Ctor` in encoding)
- #94305 (Remove an unnecessary restriction in `dest_prop`)
- #94343 (Miri fn ptr check: don't use conservative null check)
- #94344 (diagnostic: suggest parens when users want logical ops, but get closures)
- #94352 (Fix SGX docs build)
Matthias Krüger [Fri, 25 Feb 2022 13:14:41 +0000 (14:14 +0100)]
Rollup merge of #94352 - jethrogb:fix-sgx-docs-build, r=Mark-Simulacrum
Fix SGX docs build
Without this, I get
```
error[E0432]: unresolved import `crate::sys::cvt`
--> library/std/src/os/fd/owned.rs:12:5
|
12 | use crate::sys::cvt;
| ^^^^^^^^^^^^^^^ no `cvt` in `sys`
```
when running rustdoc on `std` for the x86_64-fortanix-unknown-sgx target.
Matthias Krüger [Fri, 25 Feb 2022 13:14:39 +0000 (14:14 +0100)]
Rollup merge of #94343 - RalfJung:fn-ptr, r=oli-obk
Miri fn ptr check: don't use conservative null check
In https://github.com/rust-lang/rust/pull/94270 I used the wrong NULL check for function pointers: `memory.ptr_may_be_null` is conservative even on machines that support ptr-to-int casts, leading to false errors in Miri.
This fixes that problem, and also replaces that foot-fun of a method with `scalar_may_be_null` which is never unnecessarily conservative.
Matthias Krüger [Fri, 25 Feb 2022 13:14:38 +0000 (14:14 +0100)]
Rollup merge of #94305 - JakobDegen:dp-1, r=oli-obk
Remove an unnecessary restriction in `dest_prop`
I had asked about this [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Do.20unions.20have.20active.20fields.3F) but didn't receive a response, so putting up this PR that makes the change I think we can. If it turns out that this is wrong, hopefully I'll find out here. Reposting my Zulip comment:
> Not sure what channel to put this into, so using this as a fallback. The dest prop MIR opt has this comment:
>
> ```rust
> //! Subtle case: If `dest` is a, or projects through a union, then we have to make sure that there
> //! remains an assignment to it, since that sets the "active field" of the union. But if `src` is
> //! a ZST, it might not be initialized, so there might not be any use of it before the assignment,
> //! and performing the optimization would simply delete the assignment, leaving `dest`
> //! uninitialized.
> ```
>
> In particular, the claim seems to be that we can't take
> ```
> x = ();
> y.field = x;
> ```
> where `y` is a union having `field: ()` as one of its variants, and optimize the entire thing away (assuming `x` is unused otherwise). As far as I know though, Rust unions don't have active fields. Is this comment correct and am I missing something? Is there a worry about this interacting poorly with FFI code/C unions/LTO or something?
This PR just removes that comment and the associated code. Also it fixes one unrelated comment that did not match the code it was commenting on.
Matthias Krüger [Fri, 25 Feb 2022 13:14:37 +0000 (14:14 +0100)]
Rollup merge of #94252 - lcnr:def_kind-encoding, r=cjgillot
don't special case `DefKind::Ctor` in encoding
considering that we still use `DefKind::Ctor` for these in `Res`, this seems weird and definitely felt like a bug when encountering it while working on #89862.
Matthias Krüger [Fri, 25 Feb 2022 13:14:35 +0000 (14:14 +0100)]
Rollup merge of #93845 - compiler-errors:in-band-lifetimes, r=cjgillot
Remove in band lifetimes
As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety.
Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first.
r? `@scottmcm` (or feel free to reassign, just saw your last comment on #44524)
Closes #44524
Mark Rousskov [Wed, 23 Feb 2022 13:24:20 +0000 (08:24 -0500)]
Re-add track_caller to panic_no_unwind in bootstrap
This function was updated in a recent PR (92911) to be called without the caller
information passed in, but the function signature itself was not altered with
cfg_attr at the time.
flip1995 [Fri, 25 Feb 2022 11:30:16 +0000 (11:30 +0000)]
Fix debug_assert in unused lint pass
This fixes a debug assertion in the unused lint pass. As a side effect,
this also improves the span generated for tuples in the
`unused_must_use` lint.
bors [Fri, 25 Feb 2022 11:00:32 +0000 (11:00 +0000)]
Auto merge of #93644 - michaelwoerister:simpler-debuginfo-typemap, r=wesleywiser
debuginfo: Simplify TypeMap used during LLVM debuginfo generation.
This PR simplifies the TypeMap that is used in `rustc_codegen_llvm::debuginfo::metadata`. It was unnecessarily complicated because it was originally implemented when types were not yet normalized before codegen. So it did it's own normalization and kept track of multiple unnormalized types being mapped to a single unique id.
This PR is based on https://github.com/rust-lang/rust/pull/93503, which is not merged yet.
The PR also removes the arena used for allocating string ids and instead uses `InlinableString` from the [inlinable_string](https://crates.io/crates/inlinable_string) crate. That might not be the best choice, since that crate does not seem to be very actively maintained. The [flexible-string](https://crates.io/crates/flexible-string) crate would be an alternative.
bors [Fri, 25 Feb 2022 08:40:34 +0000 (08:40 +0000)]
Auto merge of #94350 - matthiaskrgr:rollup-eesfiyr, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #92714 (Provide ignore message in the result of test)
- #93273 (Always check cg_llvm with ./x.py check)
- #94068 (Consider mutations as borrows in generator drop tracking)
- #94184 (BTree: simplify test code)
- #94297 (update const_generics_defaults release notes)
- #94341 (Remove a duplicate space)
Matthias Krüger [Fri, 25 Feb 2022 06:30:49 +0000 (07:30 +0100)]
Rollup merge of #94068 - eholk:drop-track-field-assign, r=tmandry
Consider mutations as borrows in generator drop tracking
This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points.
bors [Fri, 25 Feb 2022 03:16:22 +0000 (03:16 +0000)]
Auto merge of #93878 - Aaron1011:newtype-macro, r=cjgillot
Convert `newtype_index` to a proc macro
The `macro_rules!` implementation was becomng excessively complicated,
and difficult to modify. The new proc macro implementation should make
it much easier to add new features (e.g. skipping certain `#[derive]`s)
bors [Fri, 25 Feb 2022 00:46:04 +0000 (00:46 +0000)]
Auto merge of #93368 - eddyb:diagbld-guarantee, r=estebank
rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".
That is, `DiagnosticBuilder` is now generic over the return type of `.emit()`, so we'll now have:
* `DiagnosticBuilder<ErrorReported>` for error (incl. fatal/bug) diagnostics
* can only be created via a `const L: Level`-generic constructor, that limits allowed variants via a `where` clause, so not even `rustc_errors` can accidentally bypass this limitation
* asserts `diagnostic.is_error()` on emission, just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`)
* `.emit()` returns `ErrorReported`, as a "proof" token that `.emit()` was called
(though note that this isn't a real guarantee until after completing the work on
#69426)
* `DiagnosticBuilder<()>` for everything else (warnings, notes, etc.)
* can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()`
This PR is a companion to other ongoing work, namely:
* #69426
and it's ongoing implementation:
#93222
the API changes in this PR are needed to get statically-checked "only errors produce `ErrorReported` from `.emit()`", but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes
* #93244
would make the choices of API changes (esp. naming) in this PR fit better overall
In order to be able to let `.emit()` return anything trustable, several changes had to be made:
* `Diagnostic`'s `level` field is now private to `rustc_errors`, to disallow arbitrary "downgrade"s from "some kind of error" to "warning" (or anything else that doesn't cause compilation to fail)
* it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder`, sadly, that's harder to fix, but it's unlikely enough that we can paper over it with asserts on `.emit()`
* `.cancel()` now consumes `DiagnosticBuilder`, preventing `.emit()` calls on a cancelled diagnostic
* it's also now done internally, through `DiagnosticBuilder`-private state, instead of having a `Level::Cancelled` variant that can be read (or worse, written) by the user
* this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it, and even expect to be able to `.emit()` it
* warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early)
* `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`)
* since `.emit()` doesn't consume the `DiagnosticBuilder` <sub>(I tried and gave up, it's much more work than this PR)</sub>,
we have to make `.emit()` idempotent wrt the guarantees it returns
* thankfully, `err.emit(); err.emit();` can return `ErrorReported` both times, as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission
* `&mut Diagnostic` is now used in a lot of function signatures, which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic)
* the APIs were already mostly identical, allowing for low-effort porting to this new setup
* only some of the suggestion methods needed some rework, to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259)
* `.emit()`/`.cancel()` aren't available, but IMO calling them from an "error decorator/annotator" function isn't a good practice, and can lead to strange behavior (from the caller's perspective)
* `.downgrade_to_delayed_bug()` was added, letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same)
This PR should ideally be reviewed commit-by-commit, since there is a lot of fallout in each.
r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`
Aaron Hill [Thu, 24 Feb 2022 22:16:36 +0000 (17:16 -0500)]
Fix intra-doc link issues exposed by new macro
These links never worked, but the lint was suppressed due to the fact
that the span was pointing into the macro. With the new macro
implementation, the span now points directly to the doc comment in the
macro invocation, so it's no longer suppressed.
Aaron Hill [Wed, 9 Feb 2022 22:24:51 +0000 (17:24 -0500)]
Convert `newtype_index` to a proc macro
The `macro_rules!` implementation was becomng excessively complicated,
and difficult to modify. The new proc macro implementation should make
it much easier to add new features (e.g. skipping certain `#[derive]`s)
Dylan DPC [Thu, 24 Feb 2022 20:42:19 +0000 (21:42 +0100)]
Rollup merge of #94327 - Mark-Simulacrum:avoid-macro-sp, r=petrochenkov
Avoid emitting full macro body into JSON errors
While investigating https://github.com/rust-lang/rust/issues/94322, it was noted that currently the JSON diagnostics for macro backtraces include the full def_site span -- the whole macro body.
It seems like this shouldn't be necessary, so this PR adjusts the span to just be the "guessed head", typically the macro name. It doesn't look like we keep enough information to synthesize a nicer span here at this time.
Atop #92123, this reduces output for the src/test/ui/suggestions/missing-lifetime-specifier.rs test from 660 KB to 156 KB locally.
Dylan DPC [Thu, 24 Feb 2022 20:42:15 +0000 (21:42 +0100)]
Rollup merge of #94242 - compiler-errors:fat-uninhabitable-pointer, r=michaelwoerister
properly handle fat pointers to uninhabitable types
Calculate the pointee metadata size by using `tcx.struct_tail_erasing_lifetimes` instead of duplicating the logic in `fat_pointer_kind`. Open to alternatively suggestions on how to fix this.
Fixes #94149
r? ````@michaelwoerister```` since you touched this code last, I think!