| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=nikomatsakis
`crate` shorthand visibility modifier
cc #45388.
r? @nikomatsakis
|
|
With regrets, this breaks rustfmt and rls.
This is in the matter of #45388.
|
|
|
|
|
|
support generics in each variant of TraitItem and ImplItem
|
|
While an inner attribute here is in fact erroneous, that error ("inner
attribute is not permitted in this context") successfully gets set earlier;
this further admonition is nonsensical.
Resolves #45296.
|
|
|
|
Better error message for comma after base struct
#41834
This adds a better error for commas after the base struct:
```
let foo = Foo {
one: 111,
..Foo::default(), // This comma is a syntax error
};
```
The current error is a generic `expected one of ...` which isn't beginner-friendly. My error looks like this:
```
error: cannot use a comma after the base struct
--> tmp/example.rs:26:9
|
26 | ..Foo::default(),
| ^^^^^^^^^^^^^^^^- help: remove this comma
|
= note: the base struct expansion must always be the last field
```
I even added a note for people who don't know why this isn't allowed.
|
|
Better compile error output when using arguments instead of types
Following @estebank sugestion on issue https://github.com/rust-lang/rust/issues/18945#issuecomment-331251436
|
|
` (U+0060) should be the "grave" accent, not "Greek" accent.
|
|
output message is shown in another 'help:' block
line with +100 columns formatted
test adjusted
|
|
`let x = { ..default(), } // This comma is an error`
|
|
Improve diagnostics for `x as usize << y`
|
|
|
|
|
|
|
|
Initial support for `..=` syntax
#28237
This PR adds `..=` as a synonym for `...` in patterns and expressions.
Since `...` in expressions was never stable, we now issue a warning.
cc @durka
r? @aturon
|
|
... or ..=
|
|
Add ..= to the parser
Add ..= to libproc_macro
Add ..= to ICH
Highlight ..= in rustdoc
Update impl Debug for RangeInclusive to ..=
Replace `...` to `..=` in range docs
Make the dotdoteq warning point to the ...
Add warning for ... in expressions
Updated more tests to the ..= syntax
Updated even more tests to the ..= syntax
Updated the inclusive_range entry in unstable book
|
|
|
|
Right now the HIR contains raw `syntax::ast::Attribute` structure but nowadays
these can contain arbitrary tokens. One variant of the `Token` enum is an
"interpolated" token which basically means to shove all the tokens for a
nonterminal in this position. A "nonterminal" in this case is roughly analagous
to a macro argument:
macro_rules! foo {
($a:expr) => {
// $a is a nonterminal as an expression
}
}
Currently nonterminals contain namely items and expressions, and this poses a
problem for incremental compilation! With incremental we want a stable hash of
all HIR items, but this means we may transitively need a stable hash *of the
entire AST*, which is certainly not stable w/ node ids and whatnot. Hence today
there's a "bug" where the "stable hash" of an AST is just the raw hash value of
the AST, and this only arises with interpolated nonterminals. The downside of
this approach, however, is that a bunch of errors get spewed out during
compilation about how this isn't a great idea.
This PR is focused at fixing these warnings, basically deleting them from the
compiler. The implementation here is to alter attributes as they're lowered from
the AST to HIR, expanding all nonterminals in-place as we see them. This code
for expanding a nonterminal to a token stream already exists for the
`proc_macro` crate, so we basically just reuse the same implementation there.
After this PR it's considered a bug to have an `Interpolated` token and hence
the stable hash implementation simply uses `bug!` in this location.
Closes #40946
|
|
|
|
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
|
