| Age | Commit message (Collapse) | Author | Lines |
|---|
|
to avoid going over the existing limit now that the ui-fulldeps tests have
been moved to ui.
|
|
Rollup of 6 pull requests
Successful merges:
- #109347 (Skip no_mangle if the item has no name.)
- #109522 (Implement current_dll_path for AIX)
- #109679 (Freshen normalizes-to hack goal RHS in the evaluate loop)
- #109704 (resolve: Minor improvements to effective visibilities)
- #109739 (Closures always implement `FnOnce` in new solver)
- #109758 (Parallel compiler cleanups)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Closures always implement `FnOnce` in new solver
We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind.
Fixes compiler-errors/next-solver-hir-issues#15
r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
|
|
compiler-errors:new-solver-deep-reject-placeholder-consts, r=lcnr
Don't ICE on placeholder consts in deep reject
Since we canonicalize const params into placeholder consts, we need to be able to handle them during deep reject.
r? `@lcnr` (though maybe `@oli-obk` can look at this one too, if he wants 😸)
Fixes compiler-errors/next-solver-hir-issues#10
|
|
|
|
Canonicalize float var as float in new solver
Typo in new canonicalizer -- we should be canonicalizing float vars as `CanonicalTyVarKind::Float`, not `CanonicalTyVarKind::Int`.
Fixes compiler-errors/next-solver-hir-issues#9
|
|
Don't ICE on `DiscriminantKind` projection in new solver
As title says, since we now actually call `Ty::discriminant_kind` on placeholder types 😃
Also drive-by simplify `Pointee::Metadata` projection logic, and fix the UI test because the `<T as Pointee>::Metadata` tests weren't actually exercising the new projection logic, since we still eagerly normalize (which hits `project.rs` in the old solver) in HIR typeck.
r? `@lcnr` tho feel free to re-roll, this pr is very low-priority and not super specific to the new trait solver.
Fixes compiler-errors/next-solver-hir-issues#14
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement non-const `Destruct` trait in new solver
Makes it so that we can call stdlib methods like `Option::map` in **non-const** environments, since *many* stdlib methods have `Destruct` bounds 😅
This doesn't bother to implement `const Destruct` yet, but it shouldn't be too hard to do so. Just didn't bother since we already don't have much support for const traits in the new solver anyways. I'd be happy to add skeleton support for `const Destruct`, though, if the reviewer desires.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #108541 (Suppress `opaque_hidden_inferred_bound` for nested RPITs)
- #109137 (resolve: Querify most cstore access methods (subset 2))
- #109380 (add `known-bug` test for unsoundness issue)
- #109462 (Make alias-eq have a relation direction (and rename it to alias-relate))
- #109475 (Simpler checked shifts in MIR building)
- #109504 (Stabilize `arc_into_inner` and `rc_into_inner`.)
- #109506 (make param bound vars visibly bound vars with -Zverbose)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
new solver cleanup + implement coherence
the cleanup:
- change `Certainty::unify_and` to consider ambig + overflow to be ambig
- rename `trait_candidate_should_be_dropped_in_favor_of` to `candidate_should_be_dropped_in_favor_of`
- remove outdated fixme
For coherence I mostly just add an ambiguous candidate if the current trait ref is unknowable. I am doing the same for reservation impl where I also just add an ambiguous candidate.
|
|
|
|
|
|
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
|
|
Only implement Fn* traits for extern "Rust" safe function pointers and items
Since calling the function via an `Fn` trait will assume `extern "Rust"` ABI and not do any safety checks, only safe `extern "Rust"` function can implement the `Fn` traits. This syncs the logic between the old solver and the new solver.
r? `@compiler-errors`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Don't ICE for late-bound consts across `AnonConstBoundary`
Fixes #108194
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
feat: implement better error for manual impl of `Fn*` traits
Fixes #39259
cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Canonicalize root var when making response from new solver
During trait solving, if we equate two inference variables `?0` and `?1` but don't equate them with any rigid types, then `InferCtxt::probe_ty_var` will return `Err` for both of these. The canonicalizer code will then canonicalize the variables independently(!), and the response will not reflect the fact that these two variables have been made equal.
This hinders inference and I also don't think it's sound? I haven't thought too much about it past that, so let's talk about it.
r? ``@lcnr``
|
|
fix: evaluate with wrong obligation stack
fix #108897
r? ``@lcnr``
|
|
r=WaffleLapkin
Tweak illegal `Copy` impl message
The phrase "may not" can both mean "is not able to" and "possibly does not". Disambiguate this by just using "cannot".
``@Lokathor`` expressed being annoyed by this [here](https://twitter.com/Lokathor/status/1633200313544089602?s=20).
Also drive-by fix for this extremely noisy message: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a37275bc810f7846bfe191845b7d11d.
r? diagnostics
|
|
always resolve to universal regions if possible
`RegionConstraintCollector::opportunistic_resolve_var`, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated `'static == '1 == '2`, it doesn't resolve `'1` or `'2` to `'static`. Now it does!
Addresses review comment https://github.com/rust-lang/rust/pull/107376#discussion_r1093233687.
r? `@lcnr`
|
|
|
|
|
|
|
|
compiler-errors:non_lifetime_binders-bad-copy-clone, r=jackh726
Don't ICE when encountering bound var in builtin copy/clone bounds
Fixes #108742
|
|
Bless tests and show an introduced unsoundness related to
exits<'a> { forall<'b> { 'a == 'b } }.
We now resolve the var ?a in U0 to the placeholder !b in U1.
|
|
|
