| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
resolve: collect trait aliases along with traits
It seems trait aliases weren't being collected as `TraitCandidates` in resolve, this should change that. (I can't compile the full compiler locally, so relying on CI...)
Fixes https://github.com/rust-lang/rust/issues/56485
r? @alexreg
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
|
|
FCP: https://github.com/rust-lang/rust/issues/27745#issuecomment-373906749
|
|
make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes #56488.
Fixes #57023.
|
|
Modify some parser diagnostics to continue evaluating beyond the parser
Continue evaluating further errors after parser errors on:
- trailing type argument attribute
- lifetime in incorrect location
- incorrect binary literal
- missing `for` in `impl Trait for Foo`
- type argument in `where` clause
- incorrect float literal
- incorrect `..` in pattern
- associated types
- incorrect discriminator value variant error
and others. All of these were found by making `continue-parse-after-error` `true` by default to identify errors that would need few changes. There are now only a handful of errors that have any change with `continue-parse-after-error` enabled.
These changes make it so `rust` _won't_ stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors.
Each commit has an individual diagnostic change with their corresponding tests.
CC #48724.
|
|
|
|
|
|
Co-authored-by: Alexander Regueiro <alexreg@me.com>
|
|
Include the kind of the binding that we're suggesting, and use a
structured suggestion.
|
|
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 ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
