Add two let else regression tests
Adds a regression test for #94176, as it was fixed by #98574 but doesn't have a regression test. The PR also incorporates a commit from #94012 which added a test for an issue discovered in that PR.
Originally they have been part of #99291, but I've moved them out in the hopes of getting them merged more quickly, as that PR is already open since a month, and so that #99291 can focus on the drop order part of things.
Closes#94176Closes#96961 -- dupe of #94176
errors: don't fail on broken primary translations
If a primary bundle doesn't contain a message then the fallback bundle is used. However, if the primary bundle's message is broken (e.g. it refers to a interpolated variable that the compiler isn't providing) then this would just result in a compiler panic. While there aren't any primary bundles right now, this is the type of issue that could come up once translation is further along.
r? ```@compiler-errors``` (since this comes out of a in-person discussion we had at RustConf)
Generalize trait object generic param check to aliases.
The current algorithm only checks that `Self` does not appear in defaults for traits. This is not sufficient for trait aliases.
This PR moves the check to trait object elaboration, which sees through trait aliases.
Fixes https://github.com/rust-lang/rust/issues/82927.
Fixes https://github.com/rust-lang/rust/issues/84789.
Update to LLVM 15
For preliminary testing. Some LLVM 15 compatibility fixes were applied separately in #99512.
Release timeline:
* LLVM 15 branched on Jul 26.
* The final LLVM 15.0.0 release is scheduled for Sep 6.
* Current nightly (1.65.0) is scheduled for Nov 3.
Changes in this PR (apart from the LLVM update):
* Pass `--set llvm.allow-old-toolchain` for many Docker images. LLVM 16 will require GCC >= 7.1, while LLVM 15 still allows older compilers with an option. Specify the option for builders still using GCC 5.4. #95026 updated some of the used toolchains, but not all.
* Use the `+atomics-32` target feature for thumbv6m.
* Explicitly link libatomic when cross-compiling LLVM to 32-bit target.
* Explicitly disable zstd support, to avoid libzstd.so dependency.
New LLVM patches ([commits](https://github.com/rust-lang/llvm-project/commits/rustc/15.0-2022-08-09)):
* [rust-only] Fix ICE with GCC 5.4 (15be58d7f0)
* [rust-only] Fix build with GCC 5.4 (774edc10fa)
* ~~[rust-only] Fix build with GCC 5.2 (1a6069a7bb)~~
* ~~[rust-only] Fix ICE with GCC 5.2 (493081f290)~~
* ~~[rust-only] Fix build with GCC 5.2 (0fc5979d73)~~
* [backported] Addition of `+atomics` target feature (57bdd9892d).
* [backported] Revert compiler-rt change that broke powerpc (9c68b43915)
* [awaiting backport] Fix RelLookupTableConverter on gnux32 (639388a05f / https://github.com/llvm/llvm-project/issues/57021)
Tested images: dist-x86_64-linux, armhf-gnu, arm-android, dist-s390x-linux, dist-x86_64-illumos, dist-x86_64-freebsd, wasm32, dist-x86_64-musl, dist-various-1, dist-riscv64-linux, dist-mips-linux, dist-mipsel-linux, dist-powerpc-linux, dist-aarch64-linux, dist-x86_64-apple, x86_64-msvc-1, x86_64-msvc-2, dist-various-2, dist-arm-linux
Tested up to the usual ipv6 error: test-various, i686-gnu, x86_64-gnu-nopt
r? `@ghost`
In our source page highlighting, we were generating `<span class="op">`
tags for all "operators", including e.g. `<` `>` around generic
parameters, `*`, `&`. This contributed significantly to DOM size, but
we don't actually style `.op` except in the ayu theme.
Remove the styles for `.op` in ayu, and stop generating the `<span>`s.
This reduces DOM size of an example page[1] from 265,938 HTML elements
to 242,165 elements, a 9% reduction.
[1]:
https://doc.rust-lang.org/nightly/src/core/up/up/stdarch/crates/core_arch/src/x86/avx512f.rs.html
Stringify non-shorthand visibility correctly
This makes `stringify!(pub(in crate))` evaluate to `pub(in crate)` rather than `pub(crate)`, matching the behavior before the `crate` shorthand was removed. Further, this changes `stringify!(pub(in super))` to evaluate to `pub(in super)` rather than the current `pub(super)`. If the latter is not desired (it is _technically_ breaking), it can be undone.
Fixes#99981
`@rustbot` label +C-bug +regression-from-stable-to-beta +T-compiler
Remove duplicated temporaries creating during box derefs elaboration
Temporaries created with `MirPatch::new_temp` will be declared after
patch application. Remove manually created duplicate declarations.
Removing duplicates exposes another issue. Visitor elaborates
terminator twice and attempts to access new, but not yet available,
local declarations. Remove duplicated call to `visit_terminator`.
Extracted from #99946.
Check if enum from foreign crate has any non exhaustive variants when attempting a cast
Fixes#91161
As stated in the issue, this will require a crater run as it might break other people's stuff.
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`
#100312 was the wrong approach, I think this is the right one.
When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.
Fixes#100217Fixes#83972Fixes#84669Fixes#86710Fixes#82268Fixes#73298
Currently it's reported as either `TraitItem` or `ImplItem`. This commit
changes it to `AssocItem`, because having the report match the type name
is (a) consistent with other types, and (b) the trait/impl split isn't
that important here.
This commit:
- Adds a comment explaining which `visit_*` methods should be
implemented.
- Adds and removes some `visit_*` methods accordingly, improving
coverage, and avoiding some double counting.
Reoptimize layout array
This way it's one check instead of two, so hopefully (cc #99117) it'll be simpler for rustc perf too 🤞
Quick demonstration:
```rust
pub fn demo(n: usize) -> Option<Layout> {
Layout::array::<i32>(n).ok()
}
```
Nightly: <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=e97bf33508aa03f38968101cdeb5322d>
```nasm
mov rax, rdi
mov ecx, 4
mul rcx
seto cl
movabs rdx, 9223372036854775805
xor esi, esi
cmp rax, rdx
setb sil
shl rsi, 2
xor edx, edx
test cl, cl
cmove rdx, rsi
ret
```
This PR (note no `mul`, in addition to being much shorter):
```nasm
xor edx, edx
lea rax, [4*rcx]
shr rcx, 61
sete dl
shl rdx, 2
ret
```
This is built atop `@CAD97` 's #99136; the new changes are cb8aba66ef6a0e17f08a0574e4820653e31b45a0.
I added a bunch more tests for `Layout::from_size_align` and `Layout::array` too.
Resolves all of issue #93240
Reproduces a similar change as #99086, but with improvements
In particular, this PR inlcludes:
* redesigning the crate-search selector so the background color matches its surroundings
* decrease the font of the dropdown menu to a reaonable size
* add a hover effect
* make the color of the arrow theme-dependent, using a surrounding div, with :after pseudo-element
that can then be transformed using CSS filters to approximate the desired color
* fix the text "in" to match the title font
* remove the "for xyz" in the "Results for xyz in [All crates]" title when
searching for search term "xyz"; you can already see what you're searching for
as it's typed in the search bar!
* in line with #99086, handle super-long crate names appropriately without a long <select>
element escaping the screen area; the improvement is that we also keep the title
within a single line now; uses some flex layout shenanigans...
* the margins / paddings are adjusted so the selected label of the <select> fits within
the rest of that title nicely; also some inconsistency in the way that Firefox renders
a <select> with "appearance: none" (roughly 4px more padding left and right of the text
than e.g. Chrome) is worked around, and it now produces a result that looks (essentially)
identical to Chrome
* the color of the help menu and settings menu border in light theme is made to match with
the color of the corresponding buttons, like they do (match) in the ayu theme
* the casing of "All crates" changes to "all crates"
* the new tests from #99086 are temporarily disabled, until they can be adapted later
If a primary bundle doesn't contain a message then the fallback bundle
is used. However, if the primary bundle's message is broken (e.g. it
refers to a interpolated variable that the compiler isn't providing)
then this would just result in a compiler panic. While there aren't any
primary bundles right now, this is the type of issue that could come up
once translation is further along.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 8 pull requests
Successful merges:
- #99573 (Stabilize backtrace)
- #100069 (Add error if link_ordinal used with unsupported link kind)
- #100086 (Add more `// unit-test`s to MIR opt tests)
- #100332 (Rename integer log* methods to ilog*)
- #100334 (Suggest a missing semicolon before an array)
- #100340 (Iterate generics_def_id_map in reverse order to fix P-critical issue)
- #100345 (docs: remove repetition in `is_numeric` function docs)
- #100352 (Update cargo)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add more `// unit-test`s to MIR opt tests
I only changed things which are hopefully completely uninteresting. I plan to submit more PRs that cover more files, but those cases will need some more complicated (and hence possibly controversial) changes, so I'll try and submit those in reasonably sized batches.
r? rust-lang/wg-mir-opt
Add error if link_ordinal used with unsupported link kind
The `link_ordinal` attribute only has an affect if the `raw-dylib` link kind is used, so add an error if it is used with any other link kind.
Stabilize backtrace
This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized.
Previous discussion can be found in #72981, #3156.
Stabilized API summary:
```rust
pub mod std {
pub mod backtrace {
pub struct Backtrace { }
pub enum BacktraceStatus {
Unsupported,
Disabled,
Captured,
}
impl fmt::Debug for Backtrace {}
impl Backtrace {
pub fn capture() -> Backtrace;
pub fn force_capture() -> Backtrace;
pub const fn disabled() -> Backtrace;
pub fn status(&self) -> BacktraceStatus;
}
impl fmt::Display for Backtrace {}
}
}
```
`@yaahc`
For some reason, adding some text to match against makes this test pass.
Before, when it was *more* general, it was failing!
This seems very likely to be a bug in htmldocck, which I'm going to
investigate.
