| Age | Commit message (Collapse) | Author | Lines |
|
handle that when mir is lowered to llvm-ir more code is generated.
landingpads generates 10 llvm-ir instructions
and resume 9 llvm-ir instructions.
|
|
panic_bounds_check: use caller_location, like PanicFnLangItem
The `PanicFnLangItem` got switched to using `#[caller_location]` at some point, but `PanicBoundsCheckFnLangItem` was kept in the old style. For consistency, switch that one over to use `#[caller_location]` as well.
This is also helpful for Miri as it means the `assert_panic` machine hook never needs to know the current `Span`.
|
|
Make PlaceRef take just one lifetime
r? @eddyb
|
|
|
|
|
|
|
|
Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>
|
|
The indices do not matter here, and this fixes an index out of bounds
panic when compiling a generator that can unwind but not return.
|
|
This didn't cause issues before since generator types were always
considered to "need drop", leading to unwind paths
(including a `Resume` block) always getting generated.
|
|
|
|
|
|
|
|
mir::Local is Copy we can pass it by value in these cases
r? @oli-obk
|
|
fix various typos
|
|
Don't redundantly repeat field names (clippy::redundant_field_names)
|
|
Use .next() instead of .nth(0) on iterators.
|
|
|
|
|
|
|
|
We now have a way to apply an effect only *after* a `yield` resumes,
similar to calls (which can either return or unwind).
|
|
|
|
|
|
|
|
interpret engine: Scalar cleanup
* Remove `to_ptr`
* Make `to_bits` private
r? @oli-obk
|
|
|
|
|
|
Miri: let machine canonicalize AllocIDs
This implements the rustc side of the plan I laid out [here](https://github.com/rust-lang/miri/pull/1147#issuecomment-581868901).
Miri PR: https://github.com/rust-lang/miri/pull/1190
|
|
Use new dataflow framework for generators
#65672 introduced a new dataflow framework that can handle arbitrarily complex transfer functions as well as ones expressed as a series of gen/kill operations. This PR ports the analyses used to implement generators to the new framework so that we can remove the old one. See #68241 for a prior example of this. The new framework has some superficial API changes, but this shouldn't alter the generator passes in any way.
r? @tmandry
|
|
Rename `libsyntax` to `librustc_ast`
This was the last rustc crate that wasn't following the `rustc_*` naming convention.
Follow-up to https://github.com/rust-lang/rust/pull/67763.
|
|
|
|
use .iter() instead of .into_iter() on references
|
|
Reverse post-order requires an allocation.
|
|
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
Remove unneeded calls to format!()
|
|
use char instead of &str for single char patterns
|
|
|
|
|
|
example:
let s: String = format!("hello").into();
|
|
...to be consistent with the naming of other dataflow analyses.
|
|
|
|
|
|
|
|
|
|
|
|
Revert #69280
Resolves #69313 by reverting #69280.
After #69280, `#[rustc_args_required_const(2)]` is required on the declaration of `simd_shuffle` intrinsics. This is allowed breakage, since you can't define platform intrinsics on stable. However, the latest release of the widely used `packed_simd` crate defines these intrinsics without the requisite attribute. Since there's no urgency to merge #69280, let's revert it. We can reconsider when rust-lang/packed_simd#278 is included in a point release of `packed_simd`.
r? @petrochenkov
|
|
Fix generator miscompilations
Fixes https://github.com/rust-lang/rust/issues/69039
r? @Zoxc
|
|
ecstatic-morse:promote-shuffle-no-special-case, r=petrochenkov"
This reverts commit 61d3b6dedb1ec1f3e3cbd3d66b1a3453225bc37c, reversing
changes made to c6ad1e2c2a0c7e48537617d36085f866fa6a65a3.
|
|
Unify and improve const-prop lints
Add a single helper method for all lints emitted by const-prop, and make that lint different from the CTFE `const_err` lint. Also consistently check overflow on *arithmetic*, not on the assertion, to make behavior the same for debug and release builds.
See [this summary comment](https://github.com/rust-lang/rust/pull/69185#issuecomment-587924754) for details and the latest status.
In terms of lint formatting, I went for what seems to be the better style: have a general message above the code, and then a specific message at the span:
```
error: this arithmetic operation will overflow
--> $DIR/const-err2.rs:21:18
|
LL | let a_i128 = -std::i128::MIN;
| ^^^^^^^^^^^^^^^ attempt to negate with overflow
```
We could also just have the specific message above and no text at the span if that is preferred.
I also converted some of the existing tests to use compiletest revisions, so that the same test can check a bunch of different compile flags.
Fixes https://github.com/rust-lang/rust/issues/69020.
Helps with https://github.com/rust-lang/rust/issues/69021: debug/release are now consistent, but the assoc-const test in that issue still fails (there is a FIXME in the PR for this). The reason seems to be that const-prop notices the assoc const in `T::N << 42` and does not even bother calling `const_prop` on that operation.
Has no effect on https://github.com/rust-lang/rust/issues/61821; the duplication there has entirely different reasons.
|
|
Allow trait methods to be called on concrete types in a const context
This partially implements [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types, we are able to take advantage of the machinery in `Instance::resolve`, which is doing most of the work.
This also propagates `#[rustc_const_unstable]` from parent items to child items, making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const.
cc #67792 #57563
cc @rust-lang/wg-const-eval
r? @oli-obk
|