Fix reexport of `doc(hidden)` item
Part of #59368.
It doesn't fix the `doc(inline)` nor the `doc(hidden)` on macro. I'll do it in a follow-up PR.
r? `@notriddle`
Mark ZST as FFI-safe if all its fields are PhantomData
This presents one possible solution to issue: #106629.
This is my first (tentative) contribution to the compiler itself.
I'm looking forward for comments and feedback
Closes: #106629
[LSDA] Take ttype_index into account when taking unwind action
If `cs_action != 0`, we should check the `ttype_index` field in action record. If `ttype_index == 0`, a clean up action is taken; otherwise catch action is taken.
This can fix unwind failure on AIX which uses LLVM's libunwind by default. IIUC, rust's LSDA is borrowed from c++ and I'm assuming itanium-cxx-abi https://itanium-cxx-abi.github.io/cxx-abi/exceptions.pdf should be followed, so the fix follows what libcxxabi does. See ec48682ce9/libcxxabi/src/cxa_personality.cpp (L152) for use of `ttype_index`.
This fixes#102383 by remembering to visit the expression in
`break expr` when building the drop tracking CFG. Missing this step was
causing an off-by-one error which meant after a number of awaits we'd be
looking for dropped values at the wrong point in the code.
Additionally, this changes the order of traversal for assignment
expressions to visit the rhs and then the lhs. This matches what is done
elsewhere.
- Fixes https://github.com/rust-lang/rust/issues/91628.
- Fixes https://github.com/emscripten-core/emscripten/issues/15722.
See discussion in both issues.
The TL;DR is that weak linkage causes LLVM to produce broken Wasm, presumably due to pointer mismatch. The code is casting a void pointer to a function pointer with specific signature, but Wasm is very strict about function pointer compatibility, so the resulting code is invalid.
Ideally LLVM should catch this earlier in the process rather than emit invalid Wasm, but it currently doesn't and this is an easy and valid fix, given that Emcripten doesn't have `__cxa_thread_atexit_impl` these days anyway.
Unfortunately, I can't add a regression test as even after looking into this issue for a long time, I couldn't reproduce it with any minimal Rust example, only with extracted LLVM IR or on a large project involving Rust + C++.
r? @alexcrichton
Don't pass `--sysroot` twice if SYSROOT is set
This is useful for rust-lang/rust to allow setting a sysroot that's *only* for build scripts, different from the regular sysroot passed in RUSTFLAGS (since cargo doesn't apply RUSTFLAGS to build scripts or proc-macros).
That said, the exact motivation is not particularly important: this fixes a regression from
5907e9155e (r1060215684).
Note that only RUSTFLAGS is tested in the new integration test; passing --sysroot through `clippy-driver` never worked as far as I can tell, and no one is using it, so I didn't fix it here.
Helps with https://github.com/rust-lang/rust/pull/106394.
---
changelog: other: `SYSROOT` and `--sysroot` can now be set at the same time
[#10149](https://github.com/rust-lang/rust-clippy/pull/10149)
<!-- changelog_checked -->
Whne SYSROOT is defined, clippy-driver will insert a --sysroot argument
when calling rustc. However, when a sysroot argument is already defined,
e.g. through RUSTFLAGS=--sysroot=... the `cargo clippy` call would
error. This tests that the sysroot argument is only passed once and that
SYSROOT is ignored in this case.
This is useful for rust-lang/rust to allow setting a sysroot that's
*only* for build scripts, different from the regular sysroot passed in
RUSTFLAGS (since cargo doesn't apply RUSTFLAGS to build scripts or
proc-macros).
That said, the exact motivation is not particularly important: this
fixes a regression from
5907e9155e (r1060215684).
Note that only RUSTFLAGS is tested in the new integration test; passing
--sysroot through `clippy-driver` never worked as far as I can tell, and
no one is using it, so I didn't fix it here.
The test cases src/test/mir-opt/building/custom/consts.rs and
src/test/mir-opt/const_prop/mutable_variable_no_prop.rs are
currently failing on big-endian platforms as the binary encoding
of some constants is hard-coded in the MIR test files. Fix this
by choosing constant values that have the same encoding on big-
and little-endian platforms.
The test case src/test/mir-opt/issues/issue_75439.rs is failing
as well, but since the purpose of the test is to validate handling
of big-endian integer encodings on a little-endian platform, it does
not make much sense to run it on big-endian platforms in the first
place - we can just ignore it there.
Fixed part of https://github.com/rust-lang/rust/issues/105383.
Allow implementing `Hash` with derived `PartialEq` (`derive_hash_xor_eq`
This is a common pattern and is totally allowed by the `Hash` trait.
Fixes#2627
changelog: Move: Renamed `derive_hash_xor_eq` to [`derived_hash_with_manual_eq`]
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
changelog: Enhancement: [`derived_hash_with_manual_eq`]: Now allows `#[derive(PartialEq)]` with custom `Hash` implementations
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
<!-- changelog_checked -->
remove unreachable error code `E0490`
AFAIK, the untested and undocumented error code `E0490` is now unreachable, it was from the days of the original borrow checker.
cc ``@GuillaumeGomez`` #61137
Handle inference variables in `CollectAllMismatches` correctly
1. Fix#106240
2. Treat int/float type variables correctly (see `src/test/ui/iterators/invalid-iterator-chain-with-int-infer.rs`), so we can point out things like "`Iterator::Item` changed to `{integer}` here"
Harden the pre-tyctxt query system against accidental recomputation
While the current compiler has no issues where we `take` and then compute the query again, in https://github.com/rust-lang/rust/pull/105462 I accidentally introduced such a case.
I also took the opportunity to remove `peek_mut`, which is only ever used for `global_tcx` to then invoke `enter`. I added an `enter` method directly on the query.
