| Age | Commit message (Collapse) | Author | Lines |
|---|
|
use `def_ident_span` , `body_owner_def_id` instead of `in_progress_typeck_results`, `guess_head_span`
use `body_id.owner` directly
add description to label
|
|
It got merged so fast I didn't have time to make changes xD
|
|
`note_obligation_cause_code`
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
|
|
|
|
|
|
|
|
|
|
|
|
Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL
This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics.
Fixes https://github.com/rust-lang/rust/issues/95701
r? `@estebank`
|
|
coroutines instead of functions
|
|
|
|
|
|
|
|
Previously this test case was crashing with an index out of bounds error
deep in the call to `needs_drop`. We avoid this by detecting clearly
invalid assignees in the `mutate` callback and ignoring these.
|
|
|
|
|
|
|
|
This reverts commit 8b8f6653cfd54525714f02efe7af0a0f830e185c.
|
|
|
|
this enables consumers to access the function definition that was reported to be unsafe
|
|
oribenshir:feature/ISSUE-78543_async_fn_in_foreign_crate_diag_2, r=davidtwco
Improved diagnostic on failure to meet send bound on future in a foreign crate
Provide a better diagnostic on failure to meet send bound on futures in a foreign crate.
fixes #78543
|
|
|
|
foreign crate
Adding diagnostic data on generators to the crate metadata and using it to provide
a better diagnostic on failure to meet send bound on futures originated from a foreign crate
|
|
This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes.
The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other.
We then modify that algorithm to detect 4 cases:
- A function input is missing
- An extra argument was provided
- The type of an argument is straight up invalid
- Two arguments have been swapped
- A subset of the arguments have been shuffled
(We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.)
It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site.
The basic sketch of the algorithm is as follows:
- Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input.
- If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type".
- Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument.
- Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input
- Swapped / Permuted arguments are identified with a cycle detection algorithm.
As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again.
Note that there's a lot of extra complexity:
- We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix.
- Closure arguments are wrapped in a tuple and need to be unwrapped
- We need to resolve closure types after the rest, to allow the most specific type constraints
- We need to handle imported C functions that might be variadic in their inputs.
I tried to document a lot of this in comments in the code and keep the naming clear.
|
|
Fixes #95616
|
|
r=compiler-errors
Add note to the move size diagnostic
context: https://github.com/rust-lang/rust/issues/83518
|
|
|
|
|
|
encountered.
This also registers obligations for the hidden type immediately.
|
|
|
|
This reverts commit 6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d, reversing
changes made to 78450d2d602b06d9b94349aaf8cece1a4acaf3a8.
|
|
|
|
|
|
|
|
Fixes #94646
|
|
Reenable generator drop tracking tests and fix mutation handling
The previous PR, #94068, was overly zealous in counting mutations as borrows, which effectively nullified drop tracking. We would have caught this except the drop tracking tests were still ignored, despite having the option of using the `-Zdrop-tracking` flag now.
This PR fixes the issue introduced by #94068 by only counting mutations as borrows the mutated place has a project. This is sufficient to distinguish `x.y = 42` (which should count as a borrow of `x`) from `x = 42` (which is not a borrow of `x` because the whole variable is overwritten).
This PR also re-enables the drop tracking regression tests using the `-Zdrop-tracking` flag so we will avoid introducing these sorts of issues in the future.
Thanks to ``@tmiasko`` for noticing this problem and pointing it out!
r? ``@tmiasko``
|
|
This better captures the actual behavior, rather than using hacks around
whether the assignment has any projections.
|
|
|
|
|
|
These were still disabled from the soft revert of drop tracking, which
meant we were not catching regressions that were introduced while trying
to fix drop tracking.
|
|
Add long explanation for E0726
This is the cleaned up version of #87655 with the missing fixes.
Part of https://github.com/rust-lang/rust/issues/61137.
r? `@Urgau`
|
|
* Recover from invalid `'label: ` before block.
* Make suggestion to enclose statements in a block multipart.
* Point at `match`, `while`, `loop` and `unsafe` keywords when failing
to parse their expression.
* Do not suggest `{ ; }`.
* Do not suggest `|` when very unlikely to be what was wanted (in `let`
statements).
|
|
|
|
Remove in band lifetimes
As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety.
Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first.
r? `@scottmcm` (or feel free to reassign, just saw your last comment on #44524)
Closes #44524
|
|
Consider mutations as borrows in generator drop tracking
This is needed to match MIR more conservative approximation of any borrowed value being live across a suspend point (See #94067). This change considers an expression such as `x.y = z` to be a borrow of `x` and therefore keeps `x` live across suspend points.
r? `@nikomatsakis`
|
|
|
|
This reverts commit 3cfa4def7c87d571bd46d92fed608edf8fad236e, reversing
changes made to 5d8767cb229b097fedb1dd4bd9420d463c37774f.
|
|
This is needed to match MIR more conservative approximation of any
borrowed value being live across a suspend point (See #94067). This
change considers an expression such as `x.y = z` to be a borrow of `x`
and therefore keeps `x` live across suspend points.
|
|
Generator drop tracking: improve break and continue handling
This PR fixes two related issues.
One, sometimes break or continue have a block target instead of an expression target. This seems to mainly happen with try blocks. Since the drop tracking analysis only works on expressions, if we see a block target for break or continue, we substitute the last expression of the block as the target instead.
Two, break and continue were incorrectly being treated as the same, so continue would also show up as an exit from the loop or block. This patch corrects the way continue is handled by keeping a stack of loop entry points and uses those to find the target of the continue.
Fixes #93197
r? `@nikomatsakis`
|
|
|
