| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
Fixes rust-lang/rust#108491
Fixes rust-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
Fixes rust-lang/rust#136678 (but no test added, I don't rly care about weird IAT edge cases under GCE)
Fixes rust-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`
|
|
r=lcnr,traviscross
Stabilize `feature(generic_arg_infer)`
Fixes rust-lang/rust#85077
r? lcnr
cc ````@rust-lang/project-const-generics````
|
|
|
|
|
|
As before, add `MetaSized` and `PointeeSized` traits to all of the
non-minicore `no_core` tests so that they don't fail for lack of
language items.
|
|
r=oli-obk
Async drop - fix for StorageLive/StorageDead codegen for pinned future
Fixes: rust-lang/rust#140429, Fixes: rust-lang/rust#140531, Fixes: rust-lang/rust#141761, Fixes: rust-lang/rust#141409.
StorageLive/StorageDead codegen is corrected for pinned async drop future.
|
|
|
|
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
Fixes rust-lang/rust#79409
|
|
future
|
|
|
|
|
|
|
|
deduplicate the rest of AST walker functions
After this, we can tidy things up and deduplicate the visitor traits themselves too.
Fixes rust-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
fixes rust-lang/rust#121429
|
|
|
|
|
|
r=oli-obk
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`.
Fixes rust-lang/rust#140530
|
|
|
|
azhogin:azhogin/async-drop-unexpected-type-instead-of-drop-fn-fix, r=oli-obk
Async drop - type instead of async drop fn, fixes #140484
Fixes: rust-lang/rust#140484
Fixes: 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.
|
|
|
|
don't ICE now
|
|
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 #133066
Fixes #133199
Fixes #136894
Fixes #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 #122704
closes #139004
|
|
|
|
|
|
r=oli-obk
When AsyncDrop impl is empty, sync drop generated in elaborator
Fixes #140974.
|
|
azhogin:azhogin/async-drop-broken-mir-place-deref-fix, r=oli-obk
Async drop fix for 'broken mir, place has deref as later projection'
fixes #140975
Problem in codegen fixed with an additional temporary local.
|
|
projection' (#140975)
|
|
|
|
Avoid creating an empty identifer in `Symbol::to_ident_string`.
Because that causes an assertion failure in debug builds.
Fixes #140884.
r? `@oli-obk`
|
|
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 #113379
Fixes #121623
|
|
Because that causes an assertion failure in debug builds.
Fixes #140884.
|
|
r=nnethercote
Do not call name() on rpitit assoc_item
Fixes #141143
r? `@nnethercote`
|
|
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
|
|
|
|
|
|
|
|
Make well-formedness predicates no longer coinductive
This PR makes well-formedness no longer coinductive. It was made coinductive in https://github.com/rust-lang/rust/pull/98542, but AFAICT this was only to fix UI tests since we stopped lowering `where Ty:` to an empty-region outlives predicate but to a WF predicate instead.
Arguably it should lower to something completely different, something like a "type mentioned no-op predicate", but well-formedness serves this purpose fine today, and since no code (according to crater) relies on this coinductive behavior, we'd like to avoid having to emulate it in the new solver.
Fixes #123456 (I didn't want to add a test since it seems low-value to have a ICE test for a fuzzer minimization that is basically garbage code.)
Fixes #109764 (not sure if this behavior is emulatable w/o coinductive WF?)
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/169
r? lcnr
|
|
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
|
