We have fairly different error messages now and handle more cases,
so we augment the test in tests/ui/abi/unsupported.rs with more examples
to handle structs, traits, and impls on same when those feature
the unsupported ABIs of interest.
Only traverse reachable blocks in JumpThreading.
Fixes https://github.com/rust-lang/rust/issues/131451
We only compute loop headers for reachable blocks. We shouldn't try to perform an opt on unreachable blocks anyway.
Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs
Fixesrust-lang/rust#108491Fixesrust-lang/rust#125879
This was due to updating inhabited predicate stuff which I had to do to make constructing ADTs with IATs in fields not ICE
Fixesrust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixesrust-lang/rust#138131
Avoids doing "fully correct" candidate selection for IATs during hir ty lowering when in item signatures as it almost always leads to a query cycle from trying to build a `ParamEnv`. I replaced it with a use `DeepRejectCtxt` which should be able to handle this kind of conservative "could these types unify" while in a context where we don't want to do type equality.
This is a relatively simple scheme and should be forwards compatible with doing something more complex/powerful.
I'm not really sure how this interacts with rust-lang/rust#126651, though I'm also not really sure its super important to support projecting IATs from IAT self types given we don't even support `T::Assoc::Other` for trait-associated types so didn't give much thought to how this might fit in with that.
r? `@compiler-errors`
cc `@fmease`
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
deduplicate the rest of AST walker functions
After this, we can tidy things up and deduplicate the visitor traits themselves too.
Fixesrust-lang/rust#139825, apparently
r? ``@oli-obk``
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
Fix for async drop inside async gen fn
Return value (for yield) is corrected for async drop inside async gen function.
In CFG, when internal async drop future is polled and returned `Poll<()>::Pending`, then async gen resume function returns `Poll<(OptRet)>::Pending`.
Fixesrust-lang/rust#140530
Async drop - type instead of async drop fn, fixes#140484Fixes: rust-lang/rust#140484Fixes: rust-lang/rust#140500
Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`.
Fixes ICE, when async drop fn has wrong signature.
Report text_direction_codepoint_in_literal when parsing
The lint is now reported in code that gets removed/modified/duplicated by macro expansion, and spans are more accurate so we don't get ICEs from trying to split a span in the middle of a character.
This removes support for lint level attributes for `text_direction_codepoint_in_literal` except at the crate level, I don't think that there's an easy way around this when the lint can be reported on code that's removed by `cfg` or that is only in the input of a macro.
Fixes#140281
Defer evaluating type system constants when they use infers or params
Split out of #137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here.
I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).
This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.
Fixes#133066Fixes#133199Fixes#136894Fixes#137813
r? compiler-errors
Rollup of 7 pull requests
Successful merges:
- #135562 (Add ignore value suggestion in closure body)
- #139635 (Finalize repeat expr inference behaviour with inferred repeat counts)
- #139668 (Handle regions equivalent to 'static in non_local_bounds)
- #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths)
- #140435 (use uX::from instead of _ as uX in non - const contexts)
- #141130 (rustc_on_unimplemented cleanups)
- #141286 (Querify `coroutine_hidden_types`)
Failed merges:
- #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
r? `@ghost`
`@rustbot` modify labels: rollup
Normalize aliases to correct kind of error term
Fixes#140642
When normalizing an alias to an error in the old solver, normalize to the same term kind as the alias being normalized instead of always to a type error.
r? lcnr
Handle regions equivalent to 'static in non_local_bounds
`non_local_bounds` would only find non local bounds that strictly bound a given region, but it's possible that a local region is equated to 'static when showing a type referencing a locally bound lifetime, such as `dyn Any + 'a` in the tests added, is well-formed. In this case we should return 'static.
closes#122704closes#139004
typeck: catch `continue`s pointing to blocks
This taints the typeck results with errors if a `continue` is found not pointing to a loop.
A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness.
I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert.
Fixes#113379Fixes#121623
This taints the typeck results with errors if a `continue` is found not
pointing to a loop, which fixes an ICE.
A few things were going wrong here. First, since this wasn't caught in
typeck, we'd end up building the THIR and then running liveness lints on
ill-formed HIR. Since liveness assumes all `continue`s point to loops,
it wasn't setting a live node for the `continue`'s destination. However,
the fallback for this was faulty; it would create a new live node to
represent the erroneous state after the analysis's RWU table had already
been built. This would ICE if the new live node was used in operations,
such as merging results from the arms of a match. I've removed this
error-recovery since it was buggy, and we should really catch bad labels
before liveness.
I've also replaced an outdated comment about when liveness lints are
run. At this point, I think the call to `check_liveness` could be moved
elsewhere, but if it can be run when the typeck results are tainted by
errors, it'll need some slight refactoring so it can bail out in that
case. In lieu of that, I've added an assertion.
Resolved issue with mismatched types triggering ICE in certain scenarios
## Background
The function `annotate_mut_binding_to_immutable_binding` called in `emit_coerce_suggestions` performs a type comparison between the `expected` and `found` types from `ExpectedFound` in the `TypeError`. This can fail if the `found` type contains a region variable that's been rolled back.
## What is being changed?
This updates `annotate_mut_binding_to_immutable_binding` to use `expr_ty` and `expected` from the parent function instead of the types from the `TypeError`. This sidesteps the issue of using `found` from `TypeError` which may leak lingering inference region variables.
This does change the diagnostic behavior to _only_ support cases where the expected outermost type is `&T`, but that seems to be the intended functionality.
Also fixed the example in the `annotate_mut_binding_to_immutable_binding` rustdocs.
r? rust-lang/types
Fixes#140823
