| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Suggest removing `&`s
This implements the error message discussed in #47744.
We check whether removing each `&` yields a type that satisfies the requested obligation.
Also, it was created a new `NodeId` field in `ObligationCause` in order to iterate through the `&`s. The way it's implemented now, it iterates through the obligation snippet and counts the number of `&`.
r? @estebank
|
|
|
|
This stabilizes `main` with non-() return types; see #48453.
|
|
|
|
- Using `span_take_while` to implement others.
|
|
- `span_suggestion` changed to `span_suggestion_short`;
- `Span` used changed to contain only `&` refs;
- Tests passing.
|
|
|
|
|
|
|
|
|
|
|
|
MVP for chalkification
r? @nikomatsakis
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
|
|
Fix spans of root segments
|
|
|
|
Add the root segment for name resolution purposes only
|
|
Fix `unused_import_braces` lint false positive on `use prefix::{self as rename}`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make CodeMap and FileMap thread-safe
r? @michaelwoerister
|
|
|
|
check stability of macro invocations
I haven't implemented tests yet but this should be a pretty solid prototype. I think as-implemented it will also stability-check macro invocations in the same crate, dunno if we want that or not.
I don't know if we want this to go through `rustc::middle::stability` or not, considering the information there wouldn't be available at the time of macro expansion (even for external crates, right?).
r? @nrc
closes #34079
cc @petrochenkov @durka @jseyfried #38356
|
|
Rollup of 17 pull requests
- Successful merges: #48706, #48875, #48892, #48922, #48957, #48959, #48961, #48965, #49007, #49024, #49042, #49050, #48853, #48990, #49037, #49049, #48972
- Failed merges:
|
|
Fix ICE on malformed plugin attributes
See #48941 for some discussion.
This bug had several duplicate reports which were never closed as dupes:
Fixes #47612
Fixes #48387
Fixes #48941
Fixes #48982
|
|
Some tweaks to "type parameters from outer function" diagnostic
Follow up to #47574.
|
|
Implement import renaming with `_` (RFC 2166)
cc https://github.com/rust-lang/rust/issues/48216
|
|
They are disallowed because they have different precedence than
expressions. I assume parenthesis in pattern will be soon stabilized and
thus write that as suggestion directly.
|
|
Stabilize `match 2 { 1..=3 => {} }`.
|
|
Stabilize the syntax `a..=b` and `..=b`.
|
|
Stabilise feature(never_type). Introduce feature(exhaustive_patterns)
This stabilizes `!`, removing the feature gate as well as the old defaulting-to-`()` behavior. The pattern exhaustiveness checks which were covered by `feature(never_type)` have been moved behind a new `feature(exhaustive_patterns)` gate.
|
|
|
|
|
|
|
|
|
|
Follow up to #47574.
|
|
|
|
|
|
|
|
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
|
|
|
|
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
|
|
Show the used type variable when issuing a "can't use type parameters from outer function" error message
Fix #14844
r? @estebank
|
|
Warn about ignored generic bounds in `for`
This adds a new lint to fix #42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
|
|
Add functionality for gating feature flags on epochs ; rejigger epoch lints
fixes #48794
r? @nikomatsakis
|
|
r=estebank
in which parentheses are suggested for should-have-been-tuple-patterns
Programmers used to working in some other languages (such as Python or
Go) might expect to be able to destructure values with comma-separated
identifiers but no parentheses on the left side of an assignment.
Previously, the first name in such code would get parsed as a
single-indentifier pattern—recognizing, for example, the
`let a` in `let a, b = (1, 2);`—whereupon we would have a fatal syntax
error on seeing an unexpected comma rather than the expected semicolon
(all the way nearer to the end of `parse_full_stmt`).
Instead, let's look for that comma when parsing the pattern, and if we
see it, make-believe that we're parsing the remaining elements in a
tuple pattern, so that we can suggest wrapping it all in parentheses. We
need to do this in a separate wrapper method called on a "top-level"
pattern, rather than within
`parse_pat` itself, because `parse_pat` gets called recursively to parse
the sub-patterns within a tuple pattern.
~~We could also do this for `match` arms, `if let`, and `while let`, but
we elect not to in this patch, as it seems less likely for users to make
the mistake in those contexts.~~
Resolves #48492.
r? @petrochenkov
|
