| Age | Commit message (Collapse) | Author | Lines |
|
Fixes https://github.com/rust-lang/rust/issues/57104.
|
|
|
|
|
|
|
|
|
|
This follows ALT2 in the issue.
Fixes #56288.
|
|
|
|
|
|
This is a somewhat arbitrary restriction in order to be consistent in the
output of the tests regardless of target platform.
|
|
|
|
|
|
Take supertraits into account when calculating associated types
Fixes #24010 and #23856. Applies to trait aliases too.
As a by-product, this PR also makes repeated bindings of the same associated item in the same definition a hard error. This was previously a warning with a note about it becoming a hard error in the future. See #50589 for more info.
I talked about this with @nikomatsakis recently, but only very superficially, so this shouldn't stop anyone from assigning it to themself to review and r+.
N.B. The "WIP" commits represent imperfect attempts to solve the problem just for trait objects, but I've left them in for reference for the sake of whomever is reviewing this.
CC @carllerche @theemathas @durka @mbrubeck
|
|
|
|
|
|
|
|
I also added `// skip-codegen` to each one, to address potential concerns
that this change would otherwise slow down our test suite spending time
generating code for files that are really just meant to be checks of
compiler diagnostics.
(However, I will say: My preference is to not use `// skip-codegen` if
one can avoid it. We can use all the testing of how we drive LLVM that
we can get...)
(Updated post rebase.)
|
|
Implement trait aliases (RFC 1733)
Extends groundwork done in https://github.com/rust-lang/rust/pull/45047, and fully implements https://github.com/rust-lang/rfcs/pull/1733.
CC @durka @nikomatsakis
|
|
|
|
|
|
|
|
|
|
I’m not sure why these tests have different output now, but they do.
In all cases, the error message that is missing looks like this: “the
trait bound `dyn Trait: Trait` is not satisfied”
My guess is that the error message is going away because object-safety
now involves trait solving, and these extra error messages are no
longer leaking out.
|
|
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
|
|
|
|
It looks like we tend to use angle-brackets around the placeholder in
the few other places we use `Applicability::HasPlaceholders`, but that
would be confusing here, so ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|