The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we shuuld never warn about unused macro arms
that contain invocations of compile_error.
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
Revert "remove num_cpus dependency" in rustc and update cargo
Fixes#97549. This PR reverts #94524 and does a Cargo update to pull in rust-lang/cargo#10737.
Rust 1.61.0 has a regression in which it misidentifies the number of available CPUs in some environments, leading to enormously increased memory usage and failing builds. In between Rust 1.60 and 1.61 both rustc and cargo replaced some uses of `num_cpus` with `available_parallelism`, which eliminated support for cgroupv1, still apparently in common use. This PR switches both rustc and cargo back to using `num_cpus` in order to support environments where the available parallelism is controlled by cgroupv1. Both can use `available_parallism` again once it handles cgroupv1 (if ever).
I have confirmed that the rustc part of this PR fixes the memory usage regression in my non-Cargo environment, and others have confirmed in #97549 that the Cargo regression was at fault for the memory usage regression in their environments.
Relax mipsel-sony-psp's linker script
Previously, the linker script forcefully kept all `.lib.stub` sections, unnecessarily bloating the binary. Now, the script is LTO and `--gc-sections` friendly.
`--nmagic` was also added to the linker, because page alignment is not required on the PSP. This further reduces binary size.
Accompanying changes for the `psp` crate are found in: https://github.com/overdrivenpotato/rust-psp/pull/118
optimize `superset` method of `IntervalSet`
Given that intervals in the `IntervalSet` are sorted and strictly separated( it means the `end` of the previous interval will not be equal to the `start` of the next interval), we can reduce the complexity of the `superset` method from O(NMlogN) to O(2N) (N is the number of intervals and M is the length of each interval)
This commit adds a new unstable attribute, `#[doc(tuple_varadic)]`, that
shows a 1-tuple as `(T, ...)` instead of just `(T,)`, and links to a section
in the tuple primitive docs that talks about these.
use precise spans for recursive const evaluation
This fixes https://github.com/rust-lang/rust/issues/73283 by using a `TyCtxtAt` with a more precise span when the interpreter recursively calls itself. Hopefully such calls are sufficiently rare that this does not cost us too much performance.
(In theory, cycles can also arise through layout computation, as layout can depend on consts -- but layout computation happens all the time so we'd have to do something to not make this terrible for performance.)
Don't suggest adding `let` in certain `if` conditions
Avoid being too eager to suggest `let` in an `if` condition with an `=`, namely when the LHS of the `=` isn't even valid as a pattern (to a first degree approximation).
This heustic I came up with kinda sucks. Let me know if it needs to be refined.
Fix indices and remove some unwraps in arg mismatch algorithm
This is a more conservative fix than #97542, addressing some indices which were used incorectly and unwraps which are bound to panic (e.g. when the provided and expected arg counts differ). Beta nominating this as it's quite easy to cause ICEs -- I wrote a fuzzer and found hundreds of examples of ICEs.
cc `@jackh726` as author of #92364, and `@estebank` as reviewer of that PR.
fixes#97484
r? `@jackh726` this should be _much_ easier to review than the other PR 😅
Impl Traits lowering minor refactors
This are unrelated changes on my RPIT refactor that may be better to merge before opening the main PR.
r? `@cjgillot`
cc `@nikomatsakis`
Specify DWARF alignment in bits, not bytes.
In DWARF, alignment of types is specified in bits, as is made clear by the
parameter name `AlignInBits`. However, `rustc` was incorrectly passing a byte
alignment. This commit fixes that.
This was noticed in upstream LLVM when I tried to check in a test consisting of
LLVM IR generated from `rustc` and it triggered assertions [1].
[1]: https://reviews.llvm.org/D126835
it feels arbitrary to have `Ty` and `Const` directly
in that module and to not have `GenericArg` and
`GenericArgKind` there. Writing `ty::GenericArg`
can also feel clearer than importing it. Using
`ty::subst::GenericArg` however is ugly.
