const-eval: always do mem-to-mem copies if there might be padding involved
This is the final piece of the puzzle for https://github.com/rust-lang/rust/issues/148470: when copying data of a type that has padding, always do a mem-to-mem copy, so that we always preserve the source padding exactly. That prevents rustc implementation choices from leaking into user-visible behavior.
This is technically a breaking change: the example at the top of https://github.com/rust-lang/rust/issues/148470 no longer compiles with this. However, it seems very unlikely that anyone would have depended on this. My main concern is not backwards compatibility, it is performance.
Fixesrust-lang/rust#148470
---
> Actually that seems to be entirely fine, it even helps with some benchmarks! I guess the mem-to-mem codepath is actually faster than the scalar pair codepath for the copy itself. It can slow things down later since now we have to do everything bytewise, but that doesn't show up in our benchmarks and might not be very relevant after all (in particular, it only affects types with padding, so the rather common wide pointers still always use the efficient scalar representation).
>
> So that would be my proposal to for resolving this issue then: to make const-eval behavior consistent, we always copy the padding from the source to the target. IOW, potentially pre-existing provenance in the target always gets overwritten (that part is already in https://github.com/rust-lang/rust/pull/148259), and potentially existing provenance in padding in the source always gets carried over (that's https://github.com/rust-lang/rust/pull/148967). If there's provenance elsewhere in the source our existing handling is fine:
> - If it's in an integer, that's UB during const-eval so we can do whatever.
> - If it's in a pointer, the the fragments must combine back together to a pointer or else we have UB.
> - If it's in a union we just carry it over unchanged.
>
> @traviscross we should check that this special const-eval-only UB is properly reflected in the reference. Currently we have [this](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.const-transmute-ptr2int) but that only talks about int2ptr, not about invalid pointer fragments at pointer type. I also wonder if this shouldn't rather be part of ["invalid values"](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.validity) to make it clear that this applies recursively inside fields as well.
> EDIT: Reference PR is up at https://github.com/rust-lang/reference/pull/2091.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538447283)_
> Worth noting that this does not resolve the concerns @theemathas had about `-Zextra-const-ub-checks` sometimes causing *more* code to compile. Specifically, with that flag, the behavior changes to "potentially existing provenance in padding in the source never gets carried over". However, it's a nightly-only flag (used by Miri) so while the behavior is odd, I don't think this is a problem.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538450164)_
---
Related:
- https://github.com/rust-lang/rust/issues/148470
- https://github.com/rust-lang/reference/pull/2091
`const` blocks as a `mod` item
Tracking issue: rust-lang/rust#149226
This adds support for writing `const { ... }` as an item in a module. In the current implementation, this is a unique AST item that gets lowered to `const _: () = const { ... };` in HIR.
rustfmt support included.
TODO:
- `pub const { ... }` does not make sense (see rust-lang/rust#147136). Reject it. Should this be rejected by the parser or smth?
- Improve diagnostics (preferably they should not mention the fake `_` ident).
Improve error message for assert!() macro in functions returning bool
Detect `assert!()` macro in error messages and provide clearer diagnostics
When `assert!()` is used in a function returning a value, show a message explaining that `assert!()` doesn't return a value, instead of the generic "if may be missing an else clause" error.
Fixesrust-lang/rust#151446
Ignore `#[doc(hidden)]` items when computing trimmed paths for printing
The `trimmed_def_paths` query examines all items in the current crate, and all pub items in immediate-dependency crates (including the standard library), to see which item names are unique and can therefore be printed unambiguously as a bare name without a module path.
Currently that query has no special handling for `#[doc(hidden)]` items, which has two consequences:
- Hidden names can be considered unique, and will therefore be printed without a path, making it hard to find where that name is defined (since it normally isn't listed in documentation).
- Hidden names can conflict with visible names that would otherwise be considered unique, causing diagnostics to mysteriously become more verbose based on internal details of other crates.
This PR therefore makes the `trimmed_def_paths` query ignore external-crate items that are `#[doc(hidden)]`, along with their descendants.
As a result, hidden item names are never considered unique for trimming, and no longer interfere with visible item names being considered unique.
---
- Fixes https://github.com/rust-lang/rust/issues/148387.
`Vec::push` in consts MVP
Example:
```rust
const X: &'static [u32] = {
let mut v = Vec::with_capacity(6);
let mut x = 1;
while x < 42 {
v.push(x);
x *= 2;
}
assert!(v.len() == 6);
v.const_make_global()
};
assert_eq!([1, 2, 4, 8, 16, 32], X);
```
Oh this is fun...
* We split out the implementation of `Global` such that it calls `intrinsics::const_allocate` and `intrinsics::const_deallocate` during compile time. This is achieved using `const_eval_select`
* This allows us to `impl const Allocator for Global`
* We then constify everything necessary for `Vec::with_capacity` and `Vec::push`.
* Added `Vec::const_make_global` to leak and intern the final value via `intrinsics::const_make_global`. If we see any pointer in the final value of a `const` that did not call `const_make_global`, we error as implemented in rust-lang/rust#143595.
r? `@rust-lang/wg-const-eval`
To-do for me:
* [x] Assess the rustdoc impact of additional bounds in the method
* [x] ~~Increase test coverage~~ I think this is enough for an unstable feature.
cleaned up cast-enum-const.rs
cleaned up ufcs-trait-object-format.rs
add comment to cast-to-box-arr.rs
add comment to shadow-primitives.rs
add comment to associated-type-const-nomalization.rs
add comment to fn-trait-explicit-call.rs
add comment to call-unit-struct-impl-fn-once.rs
add comment to cast-to-char-compare.rs
add comment to self-in-method-body-resolves.rs
add comment to derive-debug-newtype-unsized-slice.rs
add comment to tuple-ref-order-distinct-impls.rs
add comment to derive-debug-generic-with-lifetime.rs
add comment to recursive-trait-bound-on-type-param.rs
cleaned up const-static-ref-to-closure.rs
add comment to const-iter-no-conflict-for-loop.rs
add comment to closure-move-use-after-move-diagnostic.rs
add comment to missing-operator-after-float.rs
add comment to closure-array-break-length.rs
add comment to box-lifetime-argument-not-allowed.rs
add comment to const-return-outside-fn.rs
add comment to drop-conflicting-impls.rs
add comment to unbalanced-doublequote-2.rs
add comment to borrow-immutable-deref-box.rs
add comment to for-in-const-eval.rs
add comment to borrowck-annotated-static-lifetime.rs
cleaned up cast-rfc0401.rs
add comment to nll-anon-to-static.rs
add comment to cast-to-dyn-any.rs
add comment to missing-associated-items.rs
add comment to enum-discriminant-missing-variant.rs
Tidying up tests/ui/issues 14 tests [5/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
move `tests/ui/inherent-impls-overlap-check` to `tests/ui/duplicate/inherent-impls-overlap-check`.
r? Kivooeo
Point at span within local macros even when error happens in nested external macro
Address issue noticed at https://users.rust-lang.org/t/error-message-does-not-specify-where-in-macro/135157/1. On errors occurring within a macro expansion, point at the innermost local macro expansion point.
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
```
error[E0308]: mismatched types
--> $DIR/macro-span-caller-replacement.rs:5:17
|
LL | s = format!("{arg}");
| ^^^^^^^^^^^^^^^^ expected `&str`, found `String`
...
LL | macro_with_format!();
| -------------------- in this macro invocation
|
= note: this error originates in the macro `format` which comes from the expansion of the macro `macro_with_format` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
Don't suggest unwrap for Result in const
closerust-lang/rust#149316
Regarding `const fn` that returns `Result`, we should avoid suggesting unwrapping. The original issue reported cases where types didn't match, but in practice, such suggestions may also appear when methods are not found, so this PR includes a fix for that case as well.
const validation: remove check for mutable refs in final value of const
This check rejects code that is not necessarily UB, e.g. a mutable ref to a `static mut` that is very carefully used correctly. That led to us having to describe it in the Reference, which uncovered just how ad-hoc this check is (https://github.com/rust-lang/reference/issues/2074).
Even without this check, we still reject things like
```rust
const C: &mut i32 = &mut 0;
```
This is rejected by const checking -- the part of the frontend that looks at the source code and says whether it is allowed in const context. In the Reference, this restriction is explained [here](https://doc.rust-lang.org/nightly/reference/const_eval.html#r-const-eval.const-expr.borrows).
So, the check during validation is just a safety net. And it is already a safety net with gaping holes since we only check `&mut T`, not `&UnsafeCell<T>`, due to the fact that we promote some immutable values that have `!Freeze` type so `&!Freeze` actually can occur in the final value of a const.
So... it may be time for me to acknowledge that the "mutable ref in final value of const" check is a cure that's worth than the disease. Nobody asked for that check, I just added it because I was worried about soundness issues when we allow mutable references in constants. Originally it was much stricter, but I had to slowly relax it to its current form to prevent t from firing on code we intend to allow. In the end there are only 3 tests left that trigger this error, and they are all just constants containing references to mutable statics -- not the safest code in the world, but also not so bad that we have to spend a lot of time devising a core language limitation and associated Reference wording to prevent it from ever happening.
So... `@rust-lang/wg-const-eval` `@rust-lang/lang` I propose that we allow code like this
```rust
static mut S: i32 = 3;
const C2: &'static mut i32 = unsafe { &mut * &raw mut S };
```
`@theemathas` would be great if you could try to poke a hole into this. ;)
Jonathan Brouwer