| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Parse nested closure with two consecutive parameter lists properly
This is a followup of #44332.
---
Currently, in nightly, this does not compile:
```rust
fn main() {
let f = |_||x, y| x+y;
println!("{}", f(())(1, 2)); // should print 3
}
```
`|_||x, y| x+y` should be parsed as `|_| (|x, y| x+y)`, but the parser didn't accept `||` between `_` and `x`. This patch fixes the problem.
r? @petrochenkov
|
|
Accept underscores in unicode escapes
Fixes #43692.
I don't know if this need an RFC, but at least the impl is here!
|
|
Add visibility to span for macros 2.0
cc https://github.com/rust-lang-nursery/rustfmt/issues/1949.
r? @nrc
|
|
|
|
|
|
|
|
|
|
Lambda expressions honor no struct literal restriction
This is a fix for #43412 if we decide that it is indeed a bug :)
closes #43412
|
|
|
|
|
|
|
|
|
|
Point out missing if conditional
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix #13483.
|
|
syntax: Relax path grammar
TLDR: Accept the disambiguator `::` in "type" paths (`Type::<Args>`), accept the disambiguator `::` before parenthesized generic arguments (`Fn::(Args)`).
The "turbofish" disambiguator `::<>` in expression paths is a necessary evil required for path parsing to be both simple and to give reasonable results.
Since paths in expressions usually refer to values (but not necessarily, e.g. `Struct::<u8> { field: 0 }` is disambiguated, but refers to a type), people often consider `::<>` to be inherent to *values*, and not *expressions* and want to write disambiguated paths for values even in contexts where disambiguation is not strictly necessary, for example when a path is passed to a macro `m!(Vec::<i32>::new)`.
The problem is that currently, if the disambiguator is not *required*, then it's *prohibited*. This results in confusion - see https://github.com/rust-lang/rust/issues/41740, https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561.
This PR makes the disambiguator *optional* instead of prohibited in contexts where it's not strictly required, so people can pass paths to macros in whatever form they consider natural (e.g. disambiguated form for value paths).
This PR also accepts the disambiguator in paths with parenthesized arguments (`Fn::(Args)`) for consistency and to simplify testing of stuff like https://github.com/rust-lang/rust/pull/41856#issuecomment-301219194.
Closes https://github.com/rust-lang/rust/issues/41740
cc @rust-lang/lang
r? @nikomatsakis
|
|
|
|
Eat open paren when parsing list in libsyntax/parse/attr.rs
This PR adds a small refactoring:
```diff
pub fn parse_meta_item_kind(&mut self) -> PResult<'a, ast::MetaItemKind> {
Ok(if self.eat(&token::Eq) {
ast::MetaItemKind::NameValue(self.parse_unsuffixed_lit()?)
- } else if self.token == token::OpenDelim(token::Paren) {
+ } else if self.eat(&token::OpenDelim(token::Paren)) {
ast::MetaItemKind::List(self.parse_meta_seq()?)
} else {
- self.eat(&token::OpenDelim(token::Paren));
ast::MetaItemKind::Word
})
}
```
in `parse_meta_item_kind()`, the parser calls `self.eat(&token::OpenDelim(token::Paren));` before returning `ast::MetaItemKind::Word` just to add `(` to expected token. It seems more natural to eat the paren when parsing `ast::MetaItemKind::List`.
|
|
|
|
|
|
Fixes #43692.
|
|
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Fix some typos
I wrote a really naive script and found those typos in the documentation.
|
|
|
|
Fix typo in unicode char definition
Reference: http://www.fileformat.info/info/unicode/char/16ed/index.htm
|
|
fix a typo
(this should not have been merged with this typo)
|
|
|
|
|
|
|
|
|
|
Hint correct extern constant syntax
Error message for `extern "C" { const …}` is terse, and the right syntax is hard to guess given unfortunate difference between meaning of `static` in C and Rust.
I've added a hint for the right syntax.
|
|
|
|
|
|
|
|
(this should not have been merged with this typo)
|
|
|
|
|
|
|
|
Also reorder and space the list to make it clearer for futures updates
and to come closer to the original list.
Thanks @est31 for the instructions.
Fixes #43629.
r? @est31
|
|
This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].
`pat_binding_modes` is populated in `librustc_typeck/check/_match.rs` and
used wherever the HIR would be scraped prior to this PR. Unfortunately, one
blemish, namely a two callers to `contains_explicit_ref_binding`, remains.
This will likely have to be removed when the second part of [1], the
`pat_adjustments` table, is tackled. Appropriate comments have been added.
See #42640.
[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
|
|
Rollup of 8 pull requests
- Successful merges: #43409, #43501, #43509, #43512, #43513, #43536, #43544, #43549
- Failed merges:
|
|
Add Span to ast::WhereClause
This PR adds `Span` field to `ast::WhereClause`. The motivation here is to make rustfmt's life easier when recovering comments before and after where clause.
r? @nrc
|
|
Throw errors when doc comments are added where they're unused
#42617
|
|
This is then later used by `proc_macro` to generate a new
`proc_macro::TokenTree` which preserves span information. Unfortunately this
isn't a bullet-proof approach as it doesn't handle the case when there's still
other attributes on the item, especially inner attributes.
Despite this the intention here is to solve the primary use case for procedural
attributes, attached to functions as outer attributes, likely bare. In this
situation we should be able to now yield a lossless stream of tokens to preserve
span information.
|
|
|
|
This commit adds a new field to the `Item` AST node in libsyntax to optionally
contain the original token stream that the item itself was parsed from. This is
currently `None` everywhere but is intended for use later with procedural
macros.
|
|
|
