| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove `-Z force-overflow-checks`
It was replaced several years ago by the stable option `-C overflow-checks`.
The goal was to delete the `-Z` flag once users had migrated [1].
Now that it's been several years, it makes sense to delete the old flag.
See also the discussion on Zulip [2].
[1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097
[2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224
r? ```@wesleywiser```
cc ```@RalfJung```
|
|
Do not visit attributes in `ItemLowerer`.
By default, AST visitors visit expressions that appear in key-value attributes.
Those expressions should not be lowered to HIR, as they do not correspond to actually compiled code.
Since an attribute cannot produce meaningful HIR, just skip them altogether.
Fixes https://github.com/rust-lang/rust/issues/81886
Fixes https://github.com/rust-lang/rust/issues/90873
r? `@michaelwoerister`
|
|
|
|
It was replaced several years ago by the stable option `-C
overflow-checks`. The goal was to delete the `-Z` flag once users had
migrated [1]. Now that it's been several years, it makes sense to delete
the old flag.
See also the discussion on Zulip [2].
[1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097
[2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224
|
|
|
|
Fix `non-constant value` ICE (#90878)
This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.
I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.
Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.
Asking Esteban to review since he was the last one to change the relevant code.
r? ``@estebank``
Fixes #90878
|
|
fix CTFE/Miri simd_insert/extract on array-style repr(simd) types
The changed test would previously fail since `place_index` would just return the only field of `f32x4`, i.e., the array -- rather than *indexing into* the array which is what we have to do.
The new helper methods will also be needed for https://github.com/rust-lang/miri/issues/1912.
r? ``````@oli-obk``````
|
|
|
|
|
|
|
|
Permit const panics in stable const contexts in stdlib
Without this change, it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code.
For example, this snippet currently fails to compile:
```rust
#[stable(feature = "foo", since = "1.0.0")]
#[rustc_const_stable(feature = "foo", since = "1.0.0")]
const fn foo() {
assert!(false);
assert!(false, "foo");
}
```
With the addition of `#[rustc_const_unstable]` to `core::panicking::panic`, the error no longer occurs. This snippet has been added verbatim in this PR as a UI test.
To avoid needing to add `#![feature(core_panic)]` to libcore, the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro.
I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)
|
|
fix getting the discriminant of a zero-variant enum
Fixes https://github.com/rust-lang/rust/issues/89765
|
|
fix ICE on Miri/CTFE copy of half a pointer
Fixes https://github.com/rust-lang/miri/issues/1910
r? `````@oli-obk`````
|
|
This also fixes the same suggestion, which was kind of broken, because it just searched for the last occurence of `const` to replace with a `let`. This works great in some cases, but when there is no const and a leading space to the file, it doesn't work and panic with overflow because it thought that it had found a const.
I also changed the suggestion to only trigger if the `const` and the non-constant value are on the same line, because if they aren't, the suggestion is very likely to be wrong.
Also don't trigger the suggestion if the found `const` is on line 0, because that triggers the ICE.
|
|
|
|
|
|
|
|
|
|
Stabilize `const_raw_ptr_deref` for `*const T`
This stabilizes dereferencing immutable raw pointers in const contexts.
It does not stabilize `*mut T` dereferencing. This is behind the
same feature gate as mutable references.
closes https://github.com/rust-lang/rust/issues/51911
|
|
|
|
Move some tests to more reasonable directories - 8
cc #73494
r? `@petrochenkov`
|
|
Add features gates for experimental asm features
This PR splits off parts of `asm!` into separate features because they are not ready for stabilization.
Specifically this adds:
- `asm_const` for `const` operands.
- `asm_sym` for `sym` operands.
- `asm_experimental_arch` for architectures other than x86, x86_64, arm, aarch64 and riscv.
r? `@nagisa`
|
|
architectures
|
|
This stabilizes dereferencing immutable raw pointers in const contexts.
It does not stabilize `*mut T` dereferencing. This is placed behind the
`const_raw_mut_ptr_deref` feature gate.
|
|
|
|
The exact set of permissions granted when forming a raw reference is
currently undecided https://github.com/rust-lang/rust/issues/56604.
To avoid presupposing any particular outcome, adjust the const
qualification to be compatible with decision where raw reference
constructed from `addr_of!` grants mutable access.
|
|
Noticed that this wasn't covered by any of existing tests.
The const checking and const qualification, which currently shares the
implementation with promotion, will likely need a different behaviour
here (see issue #90193).
|
|
Use type based qualification for unions
Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.
For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.
```rust
#![feature(untagged_unions)]
union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```
To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
Fixes #90268.
`@rust-lang/wg-const-eval`
|
|
Union field access is currently qualified based on the qualification of
a value previously assigned to the union. At the same time, every union
access transmutes the content of the union, which might result in a
different qualification.
For example, consider constants A and B as defined below, under the
current rules neither contains interior mutability, since a value used
in the initial assignment did not contain `UnsafeCell` constructor.
```rust
#![feature(untagged_unions)]
union U { i: u32, c: std::cell::Cell<u32> }
const A: U = U { i: 0 };
const B: std::cell::Cell<u32> = unsafe { U { i: 0 }.c };
```
To avoid the issue, the changes here propose to consider the content of
a union as opaque and use type based qualification for union types.
|
|
Previously a local would be qualified if either one of two separate data
flow computations indicated so. First determined if a local could
contain the qualif, but ignored any forms of indirect mutation. Second
determined if a local could be mutably borrowed (and so indirectly
mutated), but which in turn ignored the qualif.
The end result was incorrect because the effect of indirect mutation was
effectivelly ignored in the all but the final stage of computation.
In the new implementation the indirect mutation is directly incorporated
into the qualif data flow. The local variable becomes immediately
qualified once it is mutably borrowed and borrowed place type can
contain the qualif.
In general we will now reject additional programs, program that were
prevously unintentionally accepted.
There are also some cases which are now accepted but were previously
rejected, because previous implementation didn't consider whether
borrowed place could have the qualif under the consideration.
|
|
to ensure that the local qualifs are affected by the state from previous
loop iterations only if the local is kept alive.
The change should be forward compatible with a stricter handling of
indirect assignments, since storage dead invalidates all existing
pointers to the local.
|
|
Fix const qualification when executed after promotion
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
Fixes #89938.
|
|
|
|
Add test for issue #84957 - `str.as_bytes()` in a `const` expression
Hi, this PR adds a test for issue #84957 . I'm quite new to rustc so let me know if there's anything else that needs doing 😄
Closes #84957
|
|
The const qualification was so far performed before the promotion and
the implementation assumed that it will never encounter a promoted.
With `const_precise_live_drops` feature, checking for live drops is
delayed until after drop elaboration, which in turn runs after
promotion. so the assumption is no longer true. When evaluating
`NeedsNonConstDrop` it is now possible to encounter promoteds.
Use type base qualification for the promoted. It is a sound
approximation in general, and in the specific case of promoteds and
`NeedsNonConstDrop` it is precise.
|
|
Changes from #88558 allowed using `~const Drop` in constants by
introducing a new `NeedsNonConstDrop` qualif.
The new qualif was also used for promotion purposes, and allowed
promotion to happen for values that needs to be dropped but which
do have a const drop impl.
Since for promoted the drop implementation is never executed,
this lead to observable change in behaviour. For example:
```rust
struct Panic();
impl const Drop for Panic {
fn drop(&mut self) {
panic!();
}
}
fn main() {
let _ = &Panic();
}
```
Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
|
|
|
|
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
|
|
r=oli-obk
Stabilize `unreachable_unchecked` as `const fn`
Closes #53188
This PR stabilizes `core::hint::unreachable_unchecked` as `const fn`. MIRI is able to detect when this method is called. Stabilization was delayed until `const_panic` was stabilized so as to avoid users calling this method in its place (thus resulting in runtime UB). With #89508, that is no longer an issue.
````@rustbot```` label +A-const-eval +A-const-fn +T-lang +S-blocked
(not sure why it's T-lang, but that's what the tracking issue is)
|
|
|
|
add some more testcases
resolves #52893
resolves #68295
resolves #87750
resolves #88071
All these issues have been fixed according to glacier. Just adding a test so it can be closed.
Can anybody tell me why the github keywords do not work? 🤔
Please edit this post if you can fix it.
|
|
|
|
|
|
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
|
|
Follow the diagnostic output style guide
Detected by #89455.
|
|
Stabilize `const_panic`
Closes #51999
FCP completed in #89006
```@rustbot``` label +A-const-eval +A-const-fn +T-lang
cc ```@oli-obk``` for review (not `r?`'ing as not on lang team)
|
|
|
|
|
|
|
|
|
