| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Implement #[alloc_error_handler]
This to-be-stable attribute is equivalent to `#[lang = "oom"]`. It is required when using the `alloc` crate without the `std` crate. It is called by `handle_alloc_error`, which is in turned called by "infallible" allocations APIs such as `Vec::push`.
|
|
find and highlight the `&` or `'_` in `region_name`
Before:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
- | ----- lifetime `'1` appears in this argument
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
After:
```
--> $DIR/dyn-trait-underscore.rs:18:5
|
LL | fn a<T>(items: &[T]) -> Box<dyn Iterator<Item=&T>> {
+ | - let's call the lifetime of this reference `'1`
LL | Box::new(items.iter()) //~ ERROR cannot infer an appropriate lifetime
| ^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'1` must outlive `'static`
```
Not intended as the final end point necessarily in any sense. I intentionally left some to-do points to fill in later:
- Does not apply to upvars in closures yet (should be relatively easy)
- Does not handle the case where we can't find a precise match very well
- And of course we can still tweak wording
but shows the basic idea of how to make the `Ty` and `hir::Ty` to find a good spot to highlight.
r? @estebank
cc @davidtwco
|
|
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
|
|
|
|
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves #51603.
|
|
Implementation of tool lints.
Tracking issue: #44690
|
|
It's now https://github.com/rust-lang/rust/issues/52090
|
|
|
|
|
|
Show known meta items in unknown meta items error
This PR adds a label to E0541. It also factors built-in attribute parsing into a submodule of `attr` for ease of future refactoring.
Fixes #51469.
|
|
r=petrochenkov
add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions
#50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix.
Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private).
r? @nrc
cc @Manishearth
|
|
Suggest correct comparison against negative literal
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
Fix #45651.
|
|
Visibility spans were added to the AST in #47799 (d6bdf296) as a
`Spanned<_>`—which means that we need to choose a span even in the case
of inherited visibility (what you get when there's no `pub` &c. keyword
at all). That initial implementation's choice is pretty
counterintuitive, which could matter if we want to use it as a site to
suggest inserting a visibility modifier, &c.
(The phrase "Schelling span" in the comment is meant in analogy to the
game-theoretic concept of a "Schelling point", a value that is chosen
simply because it's what one can expect to agree upon with other agents
in the absence of explicit coördination.)
|
|
|
|
|
|
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves #51603.
|
|
hygiene: Implement transparent marks and use them for call-site hygiene in proc-macros
Fixes https://github.com/rust-lang/rust/issues/50050
|
|
Lowering cleanups [1/N]
|
|
|
|
|
|
|
|
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
|
|
Make FileMap::{lines, multibyte_chars, non_narrow_chars} non-mutable.
This PR removes most of the interior mutability from `FileMap`, which should be beneficial, especially in a multithreaded setting. This is achieved by initializing the state in question when the filemap is constructed instead of during lexing. Hopefully this doesn't degrade performance.
cc @wesleywiser
|
|
The method relied on the FileMap still being under construction in
order for it to do what the name promises. It's now independent of
the current state.
|
|
Namely: labels, type parameters, bindings in patterns, parameter names in functions without body.
All of these do not need hygiene after lowering to HIR, only span locations.
|
|
Lower case some feature gate error messages
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Our implementation ends up changing the `PatKind::Range` variant in the
AST to take a `Spanned<RangeEnd>` instead of just a `RangeEnd`, because
the alternative would be to try to infer the span of the range operator
from the spans of the start and end subexpressions, which is both
hideous and nontrivial to get right (whereas getting the change to the
AST right was a simple game of type tennis).
This is concerning #51043.
|
|
These were stabilized in March 2018's #47813, and are the Preferred Way
to Do It going forward (q.v. #51043).
|
|
Implementation of RFC 2086 - Allow Irrefutable Let patterns
This is the set of changes for RFC2086. Tracking issue #44495. Rendered [here](https://github.com/rust-lang/rfcs/pull/2086)
|
|
Now that `..=` inclusive ranges are stabilized, people probably
shouldn't be using `...` even in patterns, even if it's still legal
there (see #51043). To avoid drawing attention to `...` being a real
thing, let's reword this message to just say "unexpected token" rather
"cannot be used in expressions".
|
|
|
|
|
|
|
|
|
|
|
|
Move `is_builtin` for `Mark` to a separate flag
|
|
|
|
async/await
This PR implements `async`/`await` syntax for `async fn` in Rust 2015 and `async` closures and `async` blocks in Rust 2018 (tracking issue: https://github.com/rust-lang/rust/issues/50547). Limitations: non-`move` async closures with arguments are currently not supported, nor are `async fn` with multiple different input lifetimes. These limitations are not fundamental and will be removed in the future, however I'd like to go ahead and get this PR merged so we can start experimenting with this in combination with futures 0.3.
Based on https://github.com/rust-lang/rust/pull/51414.
cc @petrochenkov for parsing changes.
r? @eddyb
|
|
|
|
|
