| Age | Commit message (Collapse) | Author | Lines |
|---|
|
use .to_string() instead of format!() macro to create strings
handles what is left after https://github.com/rust-lang/rust/pull/69541
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
|
|
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
|
|
typeck: use `Pattern` obligation cause more for better diagnostics
r? @estebank
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Canonicalize inputs to const eval where needed
Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection.
This is a reattempt of #67717, in a far less invasive way.
Fixes #68477
r? @nikomatsakis
cc @eddyb
|
|
r=Mark-Simulacrum
don't use .into() to convert types into identical types.
This removes redundant `.into()` calls.
example: `let s: String = format!("hello").into();`
|
|
use find(x) instead of filter(x).next()
|
|
don't take redundant references to operands
|
|
example:
let s: String = format!("hello").into();
|
|
- update polonius-engine dependency to 0.12.0
- rustfmt the files failing tidy
|
|
Move generic arg/param validation to `create_substs_for_generic_args` to resolve various const generics issues
This changes some diagnostics, but I think they're around as helpful as the previous ones, and occur infrequently regardless.
Fixes https://github.com/rust-lang/rust/issues/68257.
Fixes https://github.com/rust-lang/rust/issues/68398.
r? @eddyb
|
|
Mark other variants as uninitialized after switch on discriminant
During drop elaboration, which builds the drop ladder that handles destruction during stack unwinding, we attempt to remove MIR `Drop` terminators that will never be reached in practice. This reduces the number of basic blocks that are passed to LLVM, which should improve performance. In #66753, a user pointed out that unreachable `Drop` terminators are common in functions like `Option::unwrap`, which move out of an `enum`. While discussing possible remedies for that issue, @eddyb suggested moving const-checking after drop elaboration. This would allow the former, which looks for `Drop` terminators and replicates a small amount of drop elaboration to determine whether a dropped local has been moved out, leverage the work done by the latter.
However, it turns out that drop elaboration is not as precise as it could be when it comes to eliminating useless drop terminators. For example, let's look at the code for `unwrap_or`.
```rust
fn unwrap_or<T>(opt: Option<T>, default: T) -> T {
match opt {
Some(inner) => inner,
None => default,
}
}
```
`opt` never needs to be dropped, since it is either moved out of (if it is `Some`) or has no drop glue (if it is `None`), and `default` only needs to be dropped if `opt` is `Some`. This is not reflected in the MIR we currently pass to codegen.
@eddyb also suggested the solution to this problem. When we switch on an enum discriminant, we should be marking all fields in other variants as definitely uninitialized. I implemented this on top of alongside a small optimization (split out into #68943) that suppresses drop terminators for enum variants with no fields (e.g. `Option::None`). This is the resulting MIR for `unwrap_or`.
In concert with #68943, this change speeds up many [optimized and debug builds](https://perf.rust-lang.org/compare.html?start=d55f3e9f1da631c636b54a7c22c1caccbe4bf0db&end=0077a7aa11ebc2462851676f9f464d5221b17d6a). We need to carefully investigate whether I have introduced any miscompilations before merging this. Code that never drops anything would be very fast indeed until memory is exhausted.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #69324 (Backport only: avoid ICE on bad placeholder type)
- #69439 (resolve: `lifetimes.rs` -> `late/lifetimes.rs`)
- #69473 (update llvm to silence gcc 9 warnings)
- #69479 (clarify operator precedence)
- #69480 (Clean up E0373 explanation)
- #69500 (Simplify the signature of par_for_each_in)
- #69505 (Enable setting diagnostic labels)
Failed merges:
r? @ghost
|
|
clarify operator precedence
|
|
Don't instantiate so many copies of drop_in_place
Split out from #66703.
r? @ghost
|
|
|
|
Generalized article_and_description
r? @matthewjasper
The logic of finding the right word and article to print seems to be repeated elsewhere... this is an experimental method to unify this logic...
|
|
|
|
remove redundant clones and import
|
|
|
|
Replace uses of Cell::get + Cell::set with Cell::replace.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix generator miscompilations
Fixes https://github.com/rust-lang/rust/issues/69039
r? @Zoxc
|
|
Querify object_safety_violations.
Split from #69076
r? @Zoxc
|
|
`lit_to_const`: gracefully bubble up type errors.
Fixes https://github.com/rust-lang/rust/issues/69310 which was injected by https://github.com/rust-lang/rust/pull/68118.
r? @pnkfelix @varkor @eddyb
cc @skinny121
|
|
r=Centril
Inline some encoding and decoding methods.
This is a small performance win.
r? @Centril
|
|
O(log n) lookup of associated items by name
Resolves #68957, in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result, the pathological case from that issue now runs in 8 seconds on my local machine, as opposed to many minutes on the current stable.
Currently, method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used, e.g., for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup, we first find all items with the same `Symbol` using binary search, then run hygienic comparison to find the one we are looking for. Ideally, this would be implemented using an insertion-order preserving, hash-based multi-map, but one is not readily available.
Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly, even if it seemed strange (I left at least one FIXME to this effect). For example, some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.
|
|
|
|
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
|
