| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 1eeb8e8b151d1da7daa73837a25dc5f7a1a7fa28, reversing
changes made to 324bf2b9fd8bf9661e7045c8a93f5ff0ec1a8ca5.
Unfortunately the assert desugaring change is not backwards compatible,
see RUST-145770.
Code such as
```rust
#[derive(Debug)]
struct F {
data: bool
}
impl std::ops::Not for F {
type Output = bool;
fn not(self) -> Self::Output { !self.data }
}
fn main() {
let f = F { data: true };
assert!(f);
}
```
would be broken by the assert desugaring change. We may need to land
the change over an edition boundary, or limit the editions that the
desugaring change impacts.
|
|
Improve C-variadic error messages: part 2
tracking issue: https://github.com/rust-lang/rust/issues/44930
a reimplementation of https://github.com/rust-lang/rust/pull/143546 that builds on https://github.com/rust-lang/rust/pull/146165.
This PR
- disallows coroutines (e.g. `async fn`) from having a `...` argument
- disallows associated functions (both in traits and standard impl blocks) from having a `...` argument
- splits up a generic "ill-formed C-variadic function" into specific errors about using an incorrect ABI, not specifying an ABI, or missing the unsafe keyword
C-variadic coroutines probably don't make sense? C-variadic functions are for FFI purposes, combining that with async functions seems weird.
For associated functions, we're just cutting scope. It's probably fine, but it's probably better to explicitly allow it. So for now, at least give a more targeted error message.
Made to be reviewed commit-by-commit.
cc `@workingjubilee`
r? compiler
|
|
|
|
|
|
|
|
|
|
MIR validation attempts to determine the number of bytes needed to
represent the size of the source type to compute the discriminant for
the inhabited target enum. For a ZST source, there is no source data to
use as a discriminant so no proper runtime check can be generated.
Since that should never be possible, insert a delayed bug to ensure the
problem has been properly reported to the user by the type checker.
|
|
|
|
|
|
|
|
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
|
|
Do not assert layout in KnownPanicsLint.
Fixes rust-lang/rust#121176
Fixes rust-lang/rust#129109
Fixes rust-lang/rust#130970
Fixes rust-lang/rust#131347
Fixes rust-lang/rust#139872
Fixes rust-lang/rust#140332
|
|
Add `ignore-backends` annotations in failing GCC backend ui tests
Follow-up of https://github.com/rust-lang/rust/pull/144125.
In the GCC backend, we don't support all ui tests yet and we have a list of tests we currently ignore available [here](https://github.com/rust-lang/rustc_codegen_gcc/blob/master/tests/failing-ui-tests.txt).
This PR adds the `ignore-backends` annotations to the corresponding ui tests.
The second commit is a fix to compiletest, complaining about `ignore-backends`.
r? ```@jieyouxu```
|
|
|
|
|
|
|
|
Consider parent predicates in ImpossiblePredicates pass.
This pass is double edged. It avoids some ICEs (yay!) but also degrades diagnostics from constant evaluation.
Fixes rust-lang/rust#121363
Fixes rust-lang/rust#131507
Fixes rust-lang/rust#140100
Fixes rust-lang/rust#140365
|
|
|
|
|
|
|
|
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
|
|
|
|
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be
terminated by a signal like `SIGABRT`. So begin having that as a hard
requirement.
Some of our current tests do terminate by a signal/crash however.
Introduce and use `run-crash` for those tests. Note that Windows crashes
are not handled by signals but by certain high bits set on the process
exit code. Example exit code for crash on Windows: `0xc000001d`.
Because of this, we define "crash" on all platforms as "not exit with
success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with
failure code 101 after panicking. As a special case, allow crashes for
`run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems
differently. Some abort (crash) the process while others exit with
failure code 1. Introduce and use `run-fail-or-crash` for such tests.
|
|
Store the type of each GVN value
MIR is fully typed, so type information is an integral part of what defines a value. GVN currently tries to circumvent storing types, which creates all sorts of complexities.
This PR stores the type along with the enum `Value` when defining a value index. This allows to simplify a lot of code.
Fixes rust-lang/rust#128094
Fixes rust-lang/rust#135128
r? ``````@ghost`````` for perf
|
|
The endianness can change the test expectation for the enum check.
This change is fixing the failing tests on big endian by changing
the tests so that they behave the same as on little endian.
|
|
Make the enum check work for negative discriminants
The discriminant check was not working correctly for negative numbers. This change fixes that by masking out the relevant bits correctly.
Fixes rust-lang/rust#143218.
|
|
The discriminant check was not working correctly for negative numbers.
This change fixes that by masking out the relevant bits correctly.
|
|
|
|
|
|
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
|
|
Similar to the existing nullpointer and alignment checks, this checks
for valid enum discriminants on creation of enums through unsafe
transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly
sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid
construction of enum values.
This PR is inspired by saethlin@'s PR
https://github.com/rust-lang/rust/pull/104862. Thank you so much for
keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
|
|
|
|
|
|
|
|
|
|
and migrate most of remaining `error-pattern`s to it.
|
|
The current alignment check does not include checks for creating
misaligned references from raw pointers, which is now added in this
patch.
When inserting the check we need to be careful with references to
field projections (e.g. `&(*ptr).a`), in which case the resulting
reference must be aligned according to the field type and not the
type of the pointer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The collection is limited to full debuginfo builds to match behavior of
FunctionCx::compute_per_local_var_debug_info.
|
|
|
|
|
|
minicore makes it much easier to add new language items to all of the
existing `no_core` tests.
|
|
|
