This optimization depends on inlining for the identity
conversions introduced by the lowering of the `?`.
To take advantage of `SimplifyArmIdentity`, `-Z mir-opt-level=2`
is required because that triggers the inlining MIR optimization.
Rollup of 5 pull requests
Successful merges:
- #65355 (Stabilize `!` in Rust 1.41.0)
- #65730 (Suggest to add lifetime constraint at explicit ouput of functions)
- #66468 (Cleanup Miri SIMD intrinsics)
- #66515 (Reduce size of `hir::Expr` by boxing more of `hir::InlineAsm`)
- #66602 (Revert "Update Source Code Pro and include italics")
Failed merges:
r? @ghost
Ignore run-make reproducible-build-2 on Mac
Ignore run-make reproducible-build-2 on Mac (we already ignore it on Windows).
Until we can dedicate resources to fixing this properly, I think we are best off just ignoring this test on platforms/contexts where it does not matter as much.
cc #66568
rustc_metadata: Privatize more things
Continuation of https://github.com/rust-lang/rust/pull/66056.
The most notable change here is that `CrateMetadata` is moved from `cstore.rs` to `decoder.rs`.
Most of uses of `CrateMetadata` fields are in the decoder and uses of `root: CrateRoot` and other fields are so intertwined with each other that it would be hard to move a part of them into `cstore.rs` to privatize `CrateMetadata` fields, so we are going the other way round.
`cstore.rs` can probably be dismantled now, but I'll leave this to some other day.
Similarly, remaining `CrateMetadata` fields can be privatized by introducing some getter/setter methods, but not today.
r? @eddyb
rustdoc: fixes#64305: disable search field instead of hidding it
The result seems to be ok but I wasn't entirely sure how to get there. I tried to stay generic a bit but maybe it's not required at all.
@GuillaumeGomez
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
Making ICEs and test them in incremental
This adds:
- A way to make the compiler ICE
- A way to check for ICE in `cfail` tests with `should-ice`
- A regression test for issue #65401
I am not sure the attribute added `should-ice` is the best for this job
The ability to print a specific item as identified by NodeId or path
seems not particularly useful, and certainly carries quite a bit of
complexity with it.
I based this solution on my reading of:
https://rethinkdb.com/blog/make-debugging-easier-with-custom-pretty-printers#what-is-still-to-be-done
That post claims that there is no clean way to check for garbage pointers, and
so this PR adopts the same solution of tentatively attempting to convert a
dererence to a string, which throws a clean exception on garbage that we can
catch and recover from.
I only made the change to vec and not the other pretty printers because I wanted
to focus my effort on the simplest thing that would resolve issue #64343. In
particular, I *considered* generalizing this fix to work on the other datatypes
in the pretty-printing support library, but I don't want to invest effort in
that until after we resolve our overall debugging support strategy; see also
issues #60826 and #65564.
Until we can dedicate resources to fixing this properly, I think we are
best off just ignoring this test on platforms/contexts where it does not
matter as much.
[RISCV] Disable Atomics on all Non-A RISC-V targets
In a `TargetOptions` configuration, `max_atomic_width: None` causes `max_atomic_width()` to return `Some(target_pointer_width)`. So, contrary to assumptions, `max_atomic_width: None` means you do have atomic support!
RISC-V's rv32i and rv32imc do not have architectural support for atomic memory accesses of any size, because they do not include the `A` architecture extension. This means the values in the target definition should be `Some(0)`.
This bug has been observed via a build failure with oreboot/oreboot#191, where LLVM was still generating libcalls for atomic operations. According to rust-lang/compiler-builtins, "Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations." - so this PR tries to bring rustc inline with this decision.
This commit also removes the outdated bug link, which references a now irrelevant GCC bug.
I will likely also have to revisit the `min_atomic_width` of all the RISC-V targets so they are correct and match what the hardware is capable of (which is more restricted than one might imagine).
r? @alexcrichton
Generate DWARF address ranges for faster lookups
This adds a new option `-Zgenerate-arange-section`, enabled by default,
corresponding to LLVM's `-generate-arange-section`. This creates a
`.debug_aranges` section with DWARF address ranges, which some tools
depend on to optimize address lookups (elfutils [22288], [25173]).
This only has effect when debuginfo is enabled, and the additional data
is small compared to the other debug sections. For example, libstd.so
with full debuginfo is about 11MB, with just 61kB in aranges.
[22288]: https://sourceware.org/bugzilla/show_bug.cgi?id=22288
[25173]: https://sourceware.org/bugzilla/show_bug.cgi?id=25173Closes#45246.
r? @michaelwoerister
Fix#53820
This fixes ICE #53820 by being more clever when matching large arrays with slice patterns.
In particular, it avoids treating large arrays like large tuples, and instead reuses the `VarLenSlice` constructor behaviour to only consider as little values as needed.
As a side-effect, such matches also get improved diagnostics, by reporting `[true, ..]` missing instead of `[true, _, _, _, _, _, _, _]`.
rustc_plugin: Remove the compatibility shim
The compatibility crate was introduced in https://github.com/rust-lang/rust/pull/62727 to migrate Cargo and some other tools, but now it's no longer necessary.
Update Source Code Pro and include italics
Fixes#65502.
A few notes:
* As stated in #65502, this does increase the download size.
* Since this PR changes the font set, I think docs.rs would have to be updated if this PR is merged.
* The fonts have a double extension (.ttf.woff); this is to keep the names consistent with the upstream font release which does that to distinguish these from the .otf.woff files ([Source Code Pro otf renders poorly on older Windows system apps](https://github.com/adobe-fonts/source-code-pro/issues/25#issuecomment-9019600)).
