| Age | Commit message (Collapse) | Author | Lines |
|
Rollup of 9 pull requests
Successful merges:
- #72271 (Improve compiler error message for wrong generic parameter order)
- #72493 ( move leak-check to during coherence, candidate eval)
- #73398 (A way forward for pointer equality in const eval)
- #73472 (Clean up E0689 explanation)
- #73496 (Account for multiple impl/dyn Trait in return type when suggesting `'_`)
- #73515 (Add second message for LiveDrop errors)
- #73567 (Clarify --extern documentation.)
- #73572 (Fix typos in doc comments)
- #73590 (bootstrap: no `config.toml` exists regression)
Failed merges:
r? @ghost
|
|
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
|
|
Also added FIXME comments to note the possible need to accommodate
counter increment calls in source-based functions that differ from the
function context of the caller instance (e.g., inline functions).
|
|
The mod uses both MIR bodies and HIR bodies, so I'm trying to maintain
consistency with these names.
|
|
|
|
switch_ty is redundant
This field is redundant, but we cannot remove it currently as pretty-printing relies on it (and it does not have access to `mir::Body` to compute the type itself).
Cc @oli-obk @matthewjasper @jonas-schievink
|
|
Make is_freeze and is_copy_modulo_regions take TyCtxtAt
Make is_freeze and is_copy_modulo_regions take TyCtxtAt instead of separately taking TyCtxt and Span. This is consistent with is_sized.
|
|
|
|
This commit adds a query that allows the CoverageData to be pulled from
a call on tcx, avoiding the need to change the
`codegen_intrinsic_call()` signature (no need to pass in the FunctionCx
or any additional arguments.
The commit does not change where/when the CoverageData is computed. It's
still done in the `pass`, and saved in the MIR `Body`.
See discussion (in progress) here:
https://github.com/rust-lang/rust/pull/73488#discussion_r443825646
|
|
r=nikomatsakis"
This reverts commit 372cb9b69c76a042d0b9d4b48ff6084f64c84a2c, reversing
changes made to 5c61a8dc34c3e2fc6d7f02cb288c350f0233f944.
|
|
|
|
|
|
Co-authored-by: Bastian Kauschke <bastian_kauschke@hotmail.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[mir-opt] Small ConstProp cleanup
|
|
|
|
everything in the diagnostic
|
|
shim.rs: avoid creating `Call` terminators calling `Self`
Also contains some cleanup and doc comment additions so I could make sense of the code.
Fixes https://github.com/rust-lang/rust/issues/73109
Closes https://github.com/rust-lang/rust/pull/73175
r? @matthewjasper
|
|
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
|
|
|
|
|
|
Co-authored-by: Tyler Mandry <tmandry@gmail.com>
|
|
This is to prevent the miscompilation in #73137 from reappearing.
Only runs with `-Zvalidate-mir`.
|
|
|
|
Replaced dummy values for hash and num_counters with computed values,
and refactored InstrumentCoverage pass to simplify injecting more
counters per function in upcoming versions.
Improved usage documentation and error messaging.
|
|
|
|
|
|
|
|
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.
|
|
first stage of implementing LLVM code coverage
This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST).
This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation.
This initial version only injects counters at the top of each function, and does not yet implement the required coverage map.
Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch.
Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
***[I put together some development notes here, under a separate branch.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
|
|
Remove const prop for indirects
This was only used by one mir-opt test and since it causes buggy behavior under `-Zmir-opt-level=2`, it seems like we should remove it.
This was split out from #71946.
Closes #72679
Closes #72372
Closes #72285
|
|
remove visit_terminator_kind from MIR visitor
For some reason, we had both `visit_terminator` and `visit_terminator_kind`. In contrast, for `Statement` we just have `visit_statement`. So this cleans things up by removing `visit_terminator_kind` and porting its users to `visit_terminator`.
|
|
Don't run generator transform when there's a TyErr
Not sure if this might cause any problems later on, but we shouldn't be hitting codegen or const eval for the produced MIR anyways, so it should be fine.
cc https://github.com/rust-lang/rust/issues/72685#issuecomment-643749020
|
|
|
|
|
|
|
|
This mode is unnecessary because it's always ok to evaluate the
right-hand side of assignments even if the left-hand side should not
have reads propagated.
|
|
|
|
Addresses feedback from @oli-obk (Thanks!)
|