| Age | Commit message (Collapse) | Author | Lines |
|---|
|
closure field capturing: don't depend on alignment of packed fields
This fixes the closure field capture part of https://github.com/rust-lang/rust/issues/115305: field capturing always stops at projections into packed structs, no matter the alignment of the field. This means changing a private field type from `u8` to `u64` can never change how closures capture fields, which is probably what we want.
Here's an example where, before this PR, changing the type of a private field in a repr(Rust) struct can change the output of a program:
```rust
#![allow(dead_code)]
mod m {
// before patch
#[derive(Default)]
pub struct S1(u8);
// after patch
#[derive(Default)]
pub struct S2(u64);
}
struct NoisyDrop;
impl Drop for NoisyDrop {
fn drop(&mut self) {
eprintln!("dropped!");
}
}
#[repr(packed)]
struct MyType {
field: m::S1, // output changes when this becomes S2
other_field: NoisyDrop,
third_field: Vec<()>,
}
fn test(r: MyType) {
let c = || {
let _val = std::ptr::addr_of!(r.field);
let _val = r.third_field;
};
drop(c);
eprintln!("before dropping");
}
fn main() {
test(MyType {
field: Default::default(),
other_field: NoisyDrop,
third_field: Vec::new(),
});
}
```
Of course this is a breaking change for the same reason that doing field capturing in the first place was a breaking change. Packed fields are relatively rare and depending on drop order is relatively rare, so I don't expect this to have much impact, but it's hard to be sure and even a crater run will only tell us so much.
Also see the [nomination comment](https://github.com/rust-lang/rust/pull/115315#issuecomment-1702807825).
Cc `@rust-lang/wg-rfc-2229` `@ehuss`
|
|
Make useless_ptr_null_checks smarter about some std functions
This teaches the `useless_ptr_null_checks` lint that some std functions can't ever return null pointers, because they need to point to valid data, get references as input, etc.
This is achieved by introducing an `#[rustc_never_returns_null_ptr]` attribute and adding it to these std functions (gated behind bootstrap `cfg_attr`).
Later on, the attribute could maybe be used to tell LLVM that the returned pointer is never null. I don't expect much impact of that though, as the functions are pretty shallow and usually the input data is already never null.
Follow-up of PR #113657
Fixes #114442
|
|
r=GuillaumeGomez
rustdoc: merge theme css into rustdoc.css
Based on https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119
Having them in separate files used to make more sense, before the migration to CSS variables made the theme files as small as they are nowadays. This is already how docs.rs and mdBook do it.
WebPageTest comparison page:
https://www.webpagetest.org/video/compare.php?tests=230913_AiDc3F_B9E,230913_AiDc7G_B9B
Filmstrip comparison:
Old waterfall:
New waterfall:
|
|
Based on
https://github.com/rust-lang/rust/pull/115812#issuecomment-1717960119
Having them in separate files used to make more sense, before the
migration to CSS variables made the theme files as small as they are
nowadays. This is already how docs.rs and mdBook do it.
|
|
|
|
Fallback effects even if types also fallback
`||` is short circuiting, so if we do ty/int var fallback, we *don't* do effect fallback 😸
r? `@fee1-dead` or `@oli-obk`
Fixes #115791
Fixes #115842
|
|
rusdoc: add gui test for custom CSS themes
Based on
https://github.com/rust-lang/rust/pull/115829#issuecomment-1720056602
|
|
|
|
Based on
https://github.com/rust-lang/rust/pull/115829#issuecomment-1720056602
|
|
Improve invalid let expression handling
- Move all of the checks for valid let expression positions to parsing.
- Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location.
- Suppress some later errors and MIR construction for invalid let expressions.
- Fix a (drop) scope issue that was also responsible for #104172.
Fixes #104172
Fixes #104868
|
|
Paper over an accidental regression
r? types
cc https://github.com/rust-lang/rust/issues/115781 (do not close issue until beta backport has been performed)
The PR reasons are explained with comments in the source.
In order to keep the diff simple, this PR effectively reverts https://github.com/rust-lang/rust/pull/113661, but only for RPITs. I will submit a follow up PR that fixes this correctly instead of just disabling the newly added check for RPITs. This PR should be significantly easier to review for beta backport
|
|
Properly consider binder vars in `HasTypeFlagsVisitor`
Given a PolyTraitRef like `for<'a> Ty: Trait` (where neither `Ty` nor `Trait` mention `'a`), we do *not* return true for `.has_type_flags(TypeFlags::HAS_LATE_BOUND)`, even though binders are supposed to act as if they have late-bound vars even if they don't mention them in their bound value: 31ae3b2bdb9376b749fc1d64b531e86806e03c73. This is because we use `HasTypeFlagsVisitor`, which only computes the type flags for `Ty`, `Const` and `Region` and `Predicates`, and we consequently skip any binders (and setting flags for their vars) that are not contained in one of these types.
This ends up causing a problem, because when we call `TyCtxt::erase_regions` (which both erases regions *and* anonymizes bound vars), we will skip such a PolyTraitRef, not anonymizing it, and therefore not making it structurally equal to other binders. This breaks vtable computations.
This PR computes the flags for all binders we enter in `HasTypeFlagsVisitor` if we're looking for `TypeFlags::HAS_LATE_BOUND` (or `TypeFlags::HAS_{RE,TY,CT}_LATE_BOUND`).
Fixes #115807
|
|
Fix the error message for `#![feature(no_coverage)]`
When #114656 was written, the feature flag to replace `no_coverage` was originally spelled `coverage`, but it was eventually changed to `coverage_attribute` instead.
That update happened to miss this error message in `removed.rs`, and unfortunately I only noticed just *after* the original PR was approved and merged.
cc ``@bossmc`` (original author) ``@oli-obk`` (original reviewer)
``@rustbot`` label +A-code-coverage
|
|
|
|
Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024
This was previously FCPed: https://github.com/rust-lang/rust/issues/71668#issuecomment-1189396886
There were two blocking requirements:
* Fix the `unused_unsafe` lint, done in https://github.com/rust-lang/rust/pull/100081
* Have `cargo fix` able to fix the lint, done in https://github.com/rust-lang/rust/pull/112017
|
|
some ConstValue refactoring
In particular, use AllocId instead of Allocation in ConstValue::ByRef. This helps avoid redundant AllocIds when a `ByRef` constant gets put back into the interpreter.
r? `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/105536
|
|
|
|
|
|
|
|
Visit ExprField for lint levels.
Fixes https://github.com/rust-lang/rust/issues/115823
|
|
|
|
|
|
Rework `no_coverage` to `coverage(off)`
As discussed at the tail of https://github.com/rust-lang/rust/issues/84605 this replaces the `no_coverage` attribute with a `coverage` attribute that takes sub-parameters (currently `off` and `on`) to control the coverage instrumentation.
Allows future-proofing for things like `coverage(off, reason="Tested live", issue="#12345")` or similar.
|
|
|
|
fix: return early when has tainted in mir pass
Fixes https://github.com/rust-lang/rust/issues/115809
As in #115643, `run_pass` is skipped if the body has tainted errors.
r? `@oli-obk`
|
|
cleanup leftovers of const_err lint
Some code / comments seem to not have been updated when const_err was turned into a hard error, so we can do a bit of cleanup here.
r? `@oli-obk`
|
|
|
|
- Add doc comment to new type
- Restore "only supported directly in conditions of `if` and `while` expressions" note
- Rename variant with clearer name
|
|
resolve: mark binding is determined after all macros had been expanded
Fixes #113834
Fixes #115377
r? `@petrochenkov`
|
|
Extend rustc -Zls
This makes it show a lot more things and thus a lot more useful.
|
|
|
|
Only suggest turbofish in patterns if we may recover
Fixes [after backport] #115780.
CC #103534.
|
|
tests: re-enable pretty-std-collections on macOS
Fixes #78665.
I made some small modifications to this test so that it would pass for me locally (though I was only able to test using lldb without built-in Rust support, but that seems to be the mode in which it would fail). I ran it a few hundred times with stage one and stage two to see if I could re-produce the spurious failures that were being reported in #78665 and couldn't. From the discussion in #78665, it seemed like this was related to Xcode versions and could be reproduced locally fairly easily. It's been a couple years since this was disabled so a lot has changed. If this starts failing spuriously again then we can disable it and I can look into that.
r? `@wesleywiser` (discussed in wg-debugging's triage meeting)
|
|
|
|
Remove assert that checks type equality
https://github.com/rust-lang/rust/pull/112307 although this prevented `unsound` issues it also seems to introduce regressions https://github.com/rust-lang/rust/issues/114858 is example of this regression. I locally tested this https://github.com/rust-lang/rust/issues/114858#issuecomment-1686502262 issue and failing assert is [this](https://www.diffchecker.com/cjb7jSQm/).
This is also related to https://github.com/rust-lang/rust/pull/115025
|
|
|
|
Read from non-scalar constants and statics in dataflow const-prop
DataflowConstProp is designed to handle scalar values. When MIR features an assignment from a non-scalar constant, we need to manually decompose it into the custom state space.
This PR tweaks interpreter callbacks to allow reusing `eval_mir_constant` without having a stack frame to get a span from.
r? `@oli-obk`
cc `@jachris`
|
|
test ABI compatibility for some unsized types as well
and test for what `DispatchFromDyn` needs.
Also I ran this on a whole bunch of targets via Miri and added enough `cfg` to make it all work, as documentation for what does and doesn't currently work. (Most of those targets do not have their tests run on CI anyway.)
Here's the shell rune I used for that:
```
for TARGET in x86_64-unknown-linux-gnu x86_64-pc-windows-gnu aarch64-unknown-linux-gnu s390x-unknown-linux-gnu mips64-unknown-linux-gnuabi64 sparc64-unknown-linux-gnu powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu riscv64gc-unknown-linux-gnu loongarch64-unknown-linux-gnu wasm32-unknown-unknown; do
BOOTSTRAP_SKIP_TARGET_SANITY=1 ./x.py run miri --stage 0 --args tests/ui/abi/compatibility.rs --target $TARGET;
done
```
|
|
|
|
|
|
|
|
|
|
Add source type for invalid bool casts
Also adds tests for casting various types to `bool` that were otherwise untested.
r? `@WaffleLapkin`
|
|
Rollup of 8 pull requests
Successful merges:
- #115548 (Extract parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule)
- #115591 (Add regression test for LLVM 17-rc3 miscompile)
- #115631 (Don't ICE when computing ctype's `repr_nullable_ptr` for possibly-unsized ty)
- #115708 (fix homogeneous_aggregate not ignoring some ZST)
- #115730 (Some more small driver refactors)
- #115749 (Allow loading the SMIR for constants and statics)
- #115757 (Add a test for #108030)
- #115761 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Add a test for #108030
Closes #108030.
This issue has been resolved in LLVM 17. I can verify that this test fails on 63a81b0c5ab336a7c8d6a9e8a812dd598a51ba18.
r? compiler
|
|
Allow loading the SMIR for constants and statics
cc https://github.com/rust-lang/project-stable-mir/issues/34
before this PR we were ICEing when trying to access the SMIR of anything other than functions
|
|
Some more small driver refactors
To improve clarity and simplify some code.
|
|
fix homogeneous_aggregate not ignoring some ZST
This is an ABI-breaking change, because it fixes bugs in our ABI code. I'm not sure what that means for this PR, we don't really have a process for such changes, do we? I can only hope nobody relied on the old buggy behavior.
Fixes https://github.com/rust-lang/rust/issues/115664
|
|
Don't ICE when computing ctype's `repr_nullable_ptr` for possibly-unsized ty
We may not always be able to compute the layout of a type like `&T` when `T: ?Sized`, even if we're able to estimate its size skeleton.
r? davidtwco
Fixes #115628
|
