Add clarification on std::cfg macro docs v. #[cfg] attribute
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes#71679
Miri: better document and fix dynamic const pattern soundness checks
https://github.com/rust-lang/const-eval/issues/42 got me thinking about soundness for consts being used in patterns, and I found a hole in our existing dynamic checks: a const referring to a mutable static *in a different crate* was not caught. This PR fixes that. It also adds some comments that explain which invariants are crucial for soundness of const-patterns.
Curiously, trying to weaponize this soundness hole failed: pattern matching compilation ICEd when encountering the cross-crate static, saying "expected allocation ID alloc0 to point to memory". I don't know why that would happen, statics *should* be entirely normal memory for pattern matching to access.
r? @oli-obk
Cc @rust-lang/wg-const-eval
Suggest deref when coercing `ty::Ref` to `ty::RawPtr`
Fixes#32122
Currently we do autoderef when casting `ty::Ref` ->`ty::Ref`, but we don't autoderef when casting `ty::Ref` -> `ty::RawPtr`. This PR make the compiler suggests deref when coercing `ty::Ref` to `ty::RawPtr`
rustc: fix check_attr() for methods, closures and foreign functions
This fixes an issue that previously turned up for methods in https://github.com/rust-lang/rust/pull/69274, but also exists for closures and foreign function: `check_attr` does not call `codegen_fn_attrs()` for these types when it should, meaning that incorrectly used function attributes are not diagnosed without codegen.
The issue affects our UI tests, as they run with `--emit=metadata` by default, but as it turns out, this is not the only case: Function attributes are not checked on any dead code without this fix!
This makes the fix a **breaking change**. The following very silly Rust programs compiles fine on stable Rust when it should not, which is fixed by this PR.
```rust
fn main() {
#[target_feature(enable = "sse2")]
|| {};
}
```
I assume any real-world program which may trigger this issue would at least emit a dead code warning, but of course that is no guarantee that such code does not exist...
Fixes#70307
Remove -Z no-landing-pads flag
Since #67502, `-Z no-landing-pads` will cause all attempted unwinds to abort since we don't generate a `try` / `catch`. This previously worked because `__rust_try` was located in libpanic_unwind which is always compiled with `-C panic=unwind`, but `__rust_try` is now directly inline into the crate that uses `catch_unwind`.
As such, `-Z no-landing-pads` is now mostly useless and people should use `-C panic=abort` instead.
Store LLVM bitcode in object files, not compressed
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
Rollup of 6 pull requests
Successful merges:
- #71507 (Document unsafety in core::ptr)
- #71572 (test iterator chain type length blowup)
- #71617 (Suggest `into` instead of `try_into` if possible with int types)
- #71627 (Fix wrong argument in autoderef process)
- #71678 (Add an index page for nightly rustc docs.)
- #71680 (Fix doc link to Eq trait from PartialEq trait)
Failed merges:
- #71597 (Rename Unique::empty() -> Unique::dangling())
r? @ghost
Fixed incorrect suggestion of `clone_double_ref` lint
- Added `<_>` to suggestion
- Changed help message
- Added new tests
Closes#5494
changelog: Improve suggestion of [`clone_double_ref`]
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes#71679
Add an index page for nightly rustc docs.
This adds an `index.html` page at the root of the nightly-rustc docs so that the URL https://doc.rust-lang.org/nightly/nightly-rustc/ should have a landing page that lists all the crates.
Fix wrong argument in autoderef process
The `overloaded_deref_ty` is a function for derefencing a type which overloads the `Deref` trait. But actually this function never uses the parameter pushed in until this PR. -_-
Suggest `into` instead of `try_into` if possible with int types
If it is possible to convert an integer type into another using `into`, don't suggest `try_into`. This commit changes the suggested method to convert from one integer type to another for the following cases:
- u{n} -> i{m} where n < m
- u8 -> isize
- i{n} -> isize where n <= 16
- u{n} -> usize where n <= 16
Fixes#71580
Document unsafety in core::ptr
Contributes to #66219
I have yet to document all the `unsafe` blocks in the lib and would like to know if I'm headed in the right direction
r? @steveklabnik
Const qualification for `StructuralEq`
Furthers #62411. Resolves#62614.
The goal of this PR is to implement the logic in #67088 on the MIR instead of the HIR. It uses the `Qualif` trait to track `StructuralPartialEq`/`StructuralEq` in the final value of a `const`. Then, if we encounter a constant during HAIR lowering whose value may not be structurally matchable, we emit the `indirect_structural_match` lint.
This PR contains all the tests present in #67088 and emits the proper warnings for the corner cases. This PR does not handle #65466, which would require that we be [more aggressive](42abbd8878/src/librustc_mir_build/hair/pattern/const_to_pat.rs (L126-L130)) when checking matched types for `PartialEq`. I think that should be done separately.
Because this works on MIR and uses dataflow, this PR should accept more cases than #67088. Notably, the qualifs in the final value of a const are encoded cross-crate, so matching on a constant whose value is defined in another crate to be `Option::<TyWithCustomEqImpl>::None` should work. Additionally, if a `const` has branching/looping, we will only emit the warning if any possible control flow path could result in a type with a custom `PartialEq` impl ending up as the final value of a `const`. I'm not sure how #67088 handled this.
AFAIK, it's not settled that these are the semantics we actually want: it's just how the `Qualif` framework happens to work. If the cross-crate part is undesirable, it would be quite easy to change the result of `mir_const_qualif().custom_eq` to `true` before encoding it in the crate metadata. This way, other crates would have to assume that all publicly exported constants may not be safe for matching.
r? @pnkfelix
cc @eddyb
Rollup of 5 pull requests
Successful merges:
- #71217 (Suggest `;` or assignment to drop borrows in tail exprs)
- #71286 (Add regression test for #69654)
- #71296 (Change wording on read_vectored docs)
- #71654 (Update link to unstable book for llvm_asm macro)
- #71657 (Add #24949 assoc constant static recursion test)
Failed merges:
r? @ghost
