| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is to address issue 84297.
|
|
|
|
|
|
Always reject `const fn` in `trait` during parsing.
'const fn' in trait are rejected in the AST:
https://github.com/rust-lang/rust/blob/b78c0d8a4d5af91a4a55d029293e3ecb879ec142/compiler/rustc_ast_passes/src/ast_validation.rs#L1411
So this feature gate check is a NOP and we can just remove it.
The src/test/ui/feature-gates/feature-gate-min_const_fn.rs and src/test/ui/feature-gates/feature-gate-const_fn.rs tests ensure that we still reject `const fn` in `trait`
Cc https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
Add allocation information to undefined behaviour errors.
So far I'm looking on information on whether the error messages are suitable.
Fixes #53325.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated
Fixes #82080.
I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations).
As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.
|
|
Make def_key and HIR parenting consistent.
r? `@petrochenkov`
|
|
|
|
Diagnostic cleanups
Follow up to #81503
Helps with #82916 (don't show note if `span` is `DUMMY_SP`)
|
|
|
|
|
|
Fixes #82080
|
|
|
|
Move some tests to more suitable subdirs
## The results from classifui
(The full results can be found here: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427)
- [lint-expr-stmt-attrs-for-early-lints.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint-expr-stmt-attrs-for-early-lints.rs) <sup>unknown</sup>: lint (1.566), feature-gates (-0.632), numbers-arithmetic (-0.955)
- [try-block.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/try-block.rs) <sup>unknown</sup>: binding (1.385), try-block (-0.097), lint (-0.932)
- [backtrace-debuginfo.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/backtrace-debuginfo.rs) <sup>unknown</sup>: macros (1.365), cfg (-0.279), drop (-0.291)
- [issues/issue-3521.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-3521.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/3521)</sup>: consts (1.298), enum (-0.872), in-band-lifetimes (-0.978)
- [impl-bounds-checking.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/impl-bounds-checking.rs) <sup>unknown</sup>: traits (1.243), for (-0.999), shadowed (-0.999)
- [issues/issue-17718.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-17718.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/17718)</sup>: binding (1.236), consts (0.315), extern (-0.779)
- [issue-6157.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issue-6157.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/6157)</sup>: regions (1.213), unboxed-closures (-0.285), traits (-0.510)
- [issues/issue-44373.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-44373.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/44373)</sup>: consts (1.187), nll (0.427), borrowck (-0.704)
- [nullable-pointer-ffi-compat.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/nullable-pointer-ffi-compat.rs) <sup>unknown</sup>: regions (1.184), consts (0.650), traits (-0.571)
- [issues/issue-52992.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-52992.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/52992)</sup>: nll (1.132), associated-types (-0.628), parser (-0.893)
- [issues/issue-2330.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2330.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/2330)</sup>: traits (1.116), directory_ownership (-0.691), compare-method (-0.981)
- [issue-74047.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issue-74047.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/74047)</sup>: async-await (1.109), impl-trait (-0.629), resolve (-0.781)
- [issues/issue-33140.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-33140.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/33140)</sup>: traits (1.063), coherence (-0.832), codemap_tests (-0.944)
- [issues/issue-28576.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-28576.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/28576)</sup>: traits (1.062), associated-types (-0.333), impl-trait (-0.697)
- [issues/issue-7222.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-7222.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/7222)</sup>: binding (1.062), consts (-0.226), numbers-arithmetic (-0.294)
- [tup.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/tup.rs) <sup>unknown</sup>: structs-enums (1.061), threads-sendsync (-0.550), moves (-0.790)
- [issues/issue-15261.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-15261.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/15261)</sup>: consts (1.052), where-clauses (-0.833), macros (-0.862)
- [issues/issue-76179.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-76179.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/76179)</sup>: associated-types (1.048), process (-0.887), rfc-2457 (-0.984)
- [issues/issue-42344.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-42344.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/42344)</sup>: borrowck (1.043), macros (-0.481), specialization (-0.966)
- [issues/issue-18661.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-18661.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/18661)</sup>: unboxed-closures (1.038), mir (-0.648), higher-rank-trait-bounds (-0.688)
- [issues/issue-2633.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-2633.rs) <sup>[issue](https://github.com/rust-lang/rust/issues/2633)</sup>: structs-enums (1.020), functions-closures (-0.722), lint (-0.967)
Some notes:
- If there are related tests (e.g. it's for the same issue), they are moved along with it.
- Moved try-block.rs to the `try-block` dir.
- Moved tup.rs to the `tuple` dir.
- Moved some tests that classified as consts to the `statics` dir, as it seems they have statics actually.
- Skipped backtrace-debuginfo.rs because I think classifui overrates their helper macros.
cc #73494
r? ```@petrochenkov```
|
|
|
|
|
|
|
|
check that first arg to `panic!()` in const is `&str`
closes #66693
~~TODO: regression test~~
cc `@RalfJung` for error message wording
|
|
|
|
fix the false 'defined here' messages
Closes #80853.
Take this code:
```rust
struct S;
fn repro_ref(thing: S) {
thing();
}
```
Previously, the error message would be this:
```
error[E0618]: expected function, found `S`
--> src/lib.rs:4:5
|
3 | fn repro_ref(thing: S) {
| ----- `S` defined here
4 | thing();
| ^^^^^--
| |
| call expression requires function
error: aborting due to previous error
```
This is incorrect as `S` is not defined in the function arguments, `thing` is defined there. With this change, the following is emitted:
```
error[E0618]: expected function, found `S`
--> $DIR/80853.rs:4:5
|
LL | fn repro_ref(thing: S) {
| ----- is of type `S`
LL | thing();
| ^^^^^--
| |
| call expression requires function
|
= note: local variable `S` is not a function
error: aborting due to previous error
```
As you can see, this error message points out that `thing` is of type `S` and later in a note, that `S` is not a function. This change does seem like a downside for some error messages. Take this example:
```
LL | struct Empty2;
| -------------- is of type `Empty2`
```
As you can see, the error message shows that the definition of `Empty2` is of type `Empty2`. Although this isn't wrong, it would be more helpful if it would say something like this (which was there previously):
```
LL | struct Empty2;
| -------------- `Empty2` defined here
```
If there is a better way of doing this, where the `Empty2` example would stay the same as without this change, please inform me.
**Update: This is now fixed**
CC `@camelid`
|
|
|
|
Improve assert_eq! and assert_ne!
This PR improves `assert_eq!` and `assert_ne!` by moving the panicking code in an external function.
It does not change the fast path, but the move of the formatting in the cold path (the panic) may have a positive effect on in instruction cache use and with inlining.
Moreover, the use of trait objects instead of generic may improve compile times for `assert_eq!`-heavy code.
Godbolt link: ~~https://rust.godbolt.org/z/TYa9MT~~ \
Updated: https://rust.godbolt.org/z/bzE84x
|
|
Move some tests to more reasonable directories - 4
cc #81941
|
|
|
|
|
|
CTFE validation: catch ReadPointerAsBytes and better error
r? ``@oli-obk``
Fixes https://github.com/rust-lang/rust/issues/79690
Cc https://github.com/rust-lang/miri/issues/1706
|
|
Suggest to create a new `const` item if the `fn` in the array is a `const fn`
Fixes #73734. If the `fn` in the array repeat expression is a `const fn`, suggest creating a new `const` item. On nightly, suggest creating an inline `const` block. This PR also removes the `suggest_const_in_array_repeat_expressions` as it is no longer necessary.
Example:
```rust
fn main() {
// Should not compile but hint to create a new const item (stable) or an inline const block (nightly)
let strings: [String; 5] = [String::new(); 5];
println!("{:?}", strings);
}
```
Gives this error:
```
error[E0277]: the trait bound `std::string::String: std::marker::Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:3:32
|
2 | let strings: [String; 5] = [String::new(); 5];
| ^^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `String`
|
= note: the `Copy` trait is required because the repeated element will be copied
```
With this change, this is the error message:
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:3:32
|
LL | let strings: [String; 5] = [String::new(); 5];
| ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`
|
= help: moving the function call to a new `const` item will resolve the error
```
|
|
|
|
|
|
|
|
improve error message for disallowed ptr-to-int casts in const eval
Improves an error message as [suggested](https://github.com/rust-lang/rust/issues/80875#issuecomment-762754580) in #80875.
Does the wording make enough sense? I tried to follow precedent for error message style while maintaining brevity.
It seems like the rest of the `ConstEvalErrKind::NeedsRfc` error messages could be improved as well. I could give that a go if this approach works.
Closes #80875
|
|
Stabilize remaining integer methods as `const fn`
This pull request stabilizes the following methods as `const fn`:
- `i*::checked_div`
- `i*::checked_div_euclid`
- `i*::checked_rem`
- `i*::checked_rem_euclid`
- `i*::div_euclid`
- `i*::overflowing_div`
- `i*::overflowing_div_euclid`
- `i*::overflowing_rem`
- `i*::overflowing_rem_euclid`
- `i*::rem_euclid`
- `i*::wrapping_div`
- `i*::wrapping_div_euclid`
- `i*::wrapping_rem`
- `i*::wrapping_rem_euclid`
- `u*::checked_div`
- `u*::checked_div_euclid`
- `u*::checked_rem`
- `u*::checked_rem_euclid`
- `u*::div_euclid`
- `u*::overflowing_div`
- `u*::overflowing_div_euclid`
- `u*::overflowing_rem`
- `u*::overflowing_rem_euclid`
- `u*::rem_euclid`
- `u*::wrapping_div`
- `u*::wrapping_div_euclid`
- `u*::wrapping_rem`
- `u*::wrapping_rem_euclid`
These can all be implemented on the current stable (1.49). There are two unstable details: const likely/unlikely and unchecked division/remainder. Both of these are for optimizations, and are in no way required to make the methods function; there is no exposure of these details publicly. Per comments below, it seems best practice is to stabilize the intrinsics. As such, `intrinsics::unchecked_div` and `intrinsics::unchecked_rem` have been stabilized as `const` as part of this pull request as well. The methods themselves remain unstable.
I believe part of the reason these were not stabilized previously was the behavior around division by 0 and modulo 0. After testing on nightly, the diagnostic for something like `const _: i8 = 5i8 % 0i8;` is similar to that of `const _: i8 = 5i8.rem_euclid(0i8);` (assuming the appropriate feature flag is enabled). As such, I believe these methods are ready to be stabilized as `const fn`.
This pull request represents the final methods mentioned in #53718. As such, this PR closes #53718.
`@rustbot` modify labels to +A-const-fn, +T-libs
|
|
Improve SIMD type element count validation
Resolves rust-lang/stdsimd#53.
These changes are motivated by `stdsimd` moving in the direction of const generic vectors, e.g.:
```rust
#[repr(simd)]
struct SimdF32<const N: usize>([f32; N]);
```
This makes a few changes:
* Establishes a maximum SIMD lane count of 2^16 (65536). This value is arbitrary, but attempts to validate lane count before hitting potential errors in the backend. It's not clear what LLVM's maximum lane count is, but cranelift's appears to be much less than `usize::MAX`, at least.
* Expands some SIMD intrinsics to support arbitrary lane counts. This resolves the ICE in the linked issue.
* Attempts to catch invalid-sized vectors during typeck when possible.
Unresolved questions:
* Generic-length vectors can't be validated in typeck and are only validated after monomorphization while computing layout. This "works", but the errors simply bail out with no context beyond the name of the type. Should these errors instead return `LayoutError` or otherwise provide context in some way? As it stands, users of `stdsimd` could trivially produce monomorphization errors by making zero-length vectors.
cc `@bjorn3`
|
|
|
|
|
|
|
