| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize `transmute` in constants and statics but not const fn
cc #53605 (leaving issue open so we can add `transmute` to `const fn` later)
Previous attempt: #64011
r? @RalfJung
cc @rust-lang/wg-const-eval
|
|
|
|
adjust ub-enum test to be endianess-independent
@cuviper noted that our test fails on "other" endianess systems (I never know which is which^^), so let's fix that.
|
|
|
|
|
|
|
|
|
|
|
|
propagation
|
|
Add second message for LiveDrop errors
This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> src/lib.rs:7:9
|
7 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
error: aborting due to previous error
```
to this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> foo.rs:6:9
|
6 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
...
10 | always_returned = never_returned;
| --------------- value is dropped here
error: aborting due to previous error
```
r? @RalfJung @ecstatic-morse
|
|
A way forward for pointer equality in const eval
r? @varkor on the first commit and @RalfJung on the second commit
cc #53020
|
|
|
|
|
|
everything in the diagnostic
|
|
|
|
|
|
|
|
We can never supply a meaningful implementation of this.
Instead, the follow up commits will create two intrinsics
that approximate comparisons:
* `ptr_maybe_eq`
* `ptr_maybe_ne`
The fact that `ptr_maybe_eq(a, b)` is not necessarily the same
value as `!ptr_maybe_ne(a, b)` is a symptom of this entire
problem.
|
|
tag/niche terminology cleanup
The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).
After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).
This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in https://github.com/rust-lang/rust/pull/72419.
(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)
r? @eddyb
|
|
Tweak "non-primitive cast" error
- Suggest borrowing expression if it would allow cast to work.
- Suggest using `<Type>::from(<expr>)` when appropriate.
- Minor tweak to `;` typo suggestion.
Partily address #47136.
|
|
- Suggest borrowing expression if it would allow cast to work.
- Suggest using `<Type>::from(<expr>)` when appropriate.
- Minor tweak to `;` typo suggestion.
Partily address #47136.
|
|
Miri: avoid tracking current location three times
Miri tracks the current instruction to execute in the call stack, but it also additionally has two `TyCtxtAt` that carry a `Span` that also tracks the current instruction. That is quite silly, so this PR uses `TyCtxt` instead, and then uses a method for computing the current span when a `TyCtxtAt` is needed. Having less redundant (semi-)global state seems like a good improvement to me. :D
To keep the ConstProp errors the same, I had to add the option to `error_to_const_error` to overwrite the span. Also for some reason this changes cycle errors a bit -- not sure if we are now better or worse as giving those queries the right span. (It is unfortunately quite easy to accidentally use `DUMMY_SP` by calling the query on a `TyCtxt` instead of a `TyCtxtAt`.)
r? @oli-obk @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
Pointer printing: do not print 0 offset
r? @eddyb Cc @oli-obk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggest to add missing feature when using gated const features
Fixes #71797
|
|
|
|
Miri: unleash all feature gates
IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is).
Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing.
r? @oli-obk @ecstatic-morse
Fixes https://github.com/rust-lang/rust/issues/71630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Copy its value to the `return_place` upon leaving a call frame
|
|
|
|
Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it.
By replicating the `ty::Error` approach to encoding "an error has occurred", all of the mechanisms that skip redundant/downstream errors are engaged and help out (see the reduction in test output).
This PR also adds `ErrorHandled::Linted` for the lint case because using `ErrorHandled::Reported` *without* having emitted an error that is *guaranteed* to stop compilation, is incorrect now.
r? @oli-obk cc @rust-lang/wg-const-eval @varkor @yodaldevoid
|
|
|
|
|
|
|
