| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
const-eval: organize and extend tests for required-consts
This includes some tests that are known-broken and hence disabled (due to https://github.com/rust-lang/rust/issues/107503).
r? `````@oli-obk`````
|
|
|
|
that were expecting the hard error for it.
I attempted to do this in a manner that preserved the line numbers to reduce the
review effort on the resulting diff, but we still have to deal with the
ramifications of how a future-incompat lint behaves compared to a hard-error (in
terms of its impact on the diagnostic output).
|
|
|
|
|
|
remove platform-intrinsics ABI; make SIMD intrinsics be regular intrinsics
`@Amanieu` `@workingjubilee` I don't think there is any reason these need to be "special"? The [original RFC](https://rust-lang.github.io/rfcs/1199-simd-infrastructure.html) indicated eventually making them stable, but I think that is no longer the plan, so seems to me like we can clean this up a bit.
Blocked on https://github.com/rust-lang/stdarch/pull/1538, https://github.com/rust-lang/rust/pull/121542.
|
|
|
|
|
|
|
|
This fixes the issue wherein the lint didn't fire for promoteds
in the case of SHL/SHR operators in non-optimized builds
and all arithmetic operators in optimized builds
|
|
|
|
|
|
|
|
r=compiler-errors
Fix ICE on field access on a tainted type after const-eval failure
Fixes #120615.
r? oli-obk or compiler
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
`Diagnostic::keys`, which is used for hashing and equating diagnostics,
has a surprising behaviour: it ignores children, but only for lints.
This was added in #88493 to fix some duplicated diagnostics, but it
doesn't seem necessary any more.
This commit removes the special case and only four tests have changed
output, with additional errors. And those additional errors aren't
exact duplicates, they're just similar. For example, in
src/tools/clippy/tests/ui/same_name_method.rs we currently have this
error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:79:9
|
LL | impl T1 for S {}
| ^^^^^^^^^^^^^^^^
```
and with this change we also get this error:
```
error: method's name is the same as an existing method in a trait
--> $DIR/same_name_method.rs:75:13
|
LL | fn foo() {}
| ^^^^^^^^^^^
|
note: existing `foo` defined here
--> $DIR/same_name_method.rs:81:9
|
LL | impl T2 for S {}
| ^^^^^^^^^^^^^^^^
```
I think printing this second argument is reasonable, possibly even
preferable to hiding it. And the other cases are similar.
|
|
provenance rather than types
|
|
Always use RevealAll for const eval queries
implements what is described in https://github.com/rust-lang/rust/pull/116803#discussion_r1364089471
Using `UserFacing` for const eval does not make sense anymore, unless we significantly change things like avoiding revealing opaque types.
New tests are copied from https://github.com/rust-lang/rust/pull/101478
|
|
|
|
|
|
Update tests
|
|
Errors in `DiagCtxtInner::emit_diagnostic` are never set to
`Level::Bug`, because the condition never succeeds, because
`self.treat_err_as_bug()` is called *before* the error counts are
incremented.
This commit switches to `self.treat_next_err_as_bug()`, fixing the
problem. This changes the error message output to actually say "internal
compiler error".
|
|
|
|
|
|
an extern type tail
|
|
Co-authored-by: Waffle Maybe <waffle.lapkin@gmail.com>
|
|
|
|
|
|
pointer occurs
|
|
r=workingjubilee
Portable SIMD subtree update
Syncs nightly to the latest changes from rust-lang/portable-simd
r? `@rust-lang/libs`
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
|
|
Const stabilize mem::discriminant
Tracking issue: #69821.
This PR is a rebase of https://github.com/rust-lang/rust/pull/103893 to resolve conflicts in library/core/src/lib.rs (against #102470 and #110393).
|
|
|
|
|
|
|
|
|
|
|
|
happens
|
|
|
|
const-eval: allow calling functions with targat features disabled at compile time in WASM
This is not unsafe on WASM, see https://github.com/rust-lang/rust/pull/84988
r? `@RalfJung`
Fixes https://github.com/rust-lang/rust/issues/116516
|
|
time in WASM
This is not unsafe on WASM, see https://github.com/rust-lang/rust/pull/84988
|
|
const_eval: allow function pointer signatures containing &mut T in const contexts
potentially fixes #114994
We utilize a `TypeVisitor` here in order to more easily handle control flow.
- In the event the typekind the Visitor sees is a function pointer, we skip over it
- However, otherwise we do one of two things:
- If we find a mutable reference, check it, then continue visiting types
- If we find any other type, continue visiting types
This means we will check if the function pointer _itself_ is mutable, but not if any of the types _within_ are.
|
|
const-eval: make misalignment a hard error
It's been a future-incompat error (showing up in cargo's reports) since https://github.com/rust-lang/rust/pull/104616, Rust 1.68, released in March. That should be long enough.
The question for the lang team is simply -- should we move ahead with this, making const-eval alignment failures a hard error? (It turns out some of them accidentally already were hard errors since #104616. But not all so this is still a breaking change. Crater found no regression.)
|
