Commit Graph

119 Commits

Author SHA1 Message Date
bors
29d8fb746d Auto merge of #88386 - estebank:unmatched-delims, r=jackh726
Point at unclosed delimiters as part of the primary MultiSpan

Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.

_Context: https://twitter.com/mwk4/status/1430631546432675840_
2021-09-03 03:13:18 +00:00
bors
ae0b03bc6b Auto merge of #88262 - klensy:pprust-cow, r=nagisa
Cow'ify some pprust methods

Reduce number of potential needless de/allocations by using `Cow<'static, str>` instead of explicit `String` type.
2021-08-29 17:46:29 +00:00
Esteban Kuber
c6d800d854 Point at unclosed delimiters as part of the primary MultiSpan
Both the place where the parser encounters a needed closed delimiter and
the unclosed opening delimiter are important, so they should get the
same level of highlighting in the output.
2021-08-27 14:24:47 +00:00
klensy
c565339c37 Convert some functions to return Cow<'static,str> instead of String to reduce potential reallocations 2021-08-25 00:24:44 +03:00
Frank Steffahn
bf88b113ea Fix typos “a”→“an” 2021-08-22 15:35:11 +02:00
Fabian Wolff
2362450425 Suggest a path separator if a stray colon is found in a match arm
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
2021-07-14 01:15:59 +02:00
Vadim Petrochenkov
cbdfa1edca parser: Ensure that all nonterminals have tokens after parsing 2021-06-06 14:21:12 +03:00
Joshua Nelson
e48b6b4599 Stabilize extended_key_value_attributes
# Stabilization report

 ## Summary

This stabilizes using macro expansion in key-value attributes, like so:

 ```rust
 #[doc = include_str!("my_doc.md")]
 struct S;

 #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
 mod m;
 ```

See the changes to the reference for details on what macros are allowed;
see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
for alternatives that were considered and rejected ("why accept no more
and no less?")

This has been available on nightly since 1.50 with no major issues.

 ## Notes

 ### Accepted syntax

The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.

 ### Expansion ordering

Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.

There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).

 ## Test cases

 - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
 - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs

The feature has also been dogfooded extensively in the compiler and
standard library:

- https://github.com/rust-lang/rust/pull/83329
- https://github.com/rust-lang/rust/pull/83230
- https://github.com/rust-lang/rust/pull/82641
- https://github.com/rust-lang/rust/pull/80534

 ## Implementation history

- Initial proposal: https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
- Experiment to see how much code it would break: https://github.com/rust-lang/rust/pull/67121
- Preliminary work to restrict expansion that would conflict with this
feature: https://github.com/rust-lang/rust/pull/77271
- Initial implementation: https://github.com/rust-lang/rust/pull/78837
- Fix for an ICE: https://github.com/rust-lang/rust/pull/80563

 ## Unresolved Questions

~~https://github.com/rust-lang/rust/pull/83366#issuecomment-805180738 listed some concerns, but they have been resolved as of this final report.~~

 ## Additional Information

 There are two workarounds that have a similar effect for `#[doc]`
attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:

```rust
macro_rules! forward_inner_docs {
    ($e:expr => $i:item) => {
        #[doc = $e]
        $i
    };
}

forward_inner_docs!(include_str!("lib.rs") => struct S {});
```

This also works for other attributes (like `#[path = concat!(...)]`).
The other is to use `doc(include)`:

```rust
 #![feature(external_doc)]
 #[doc(include = "lib.rs")]
 struct S {}
```

The first works, but is non-trivial for people to discover, and
difficult to read and maintain. The second is a strange special-case for
a particular use of the macro. This generalizes it to work for any use
case, not just including files.

I plan to remove `doc(include)` when this is stabilized. The
`forward_inner_docs` workaround will still compile without warnings, but
I expect it to be used less once it's no longer necessary.
2021-05-18 01:01:36 -04:00
bors
2fb1dee14b Auto merge of #85104 - hi-rustin:rustin-patch-typo, r=jonas-schievink
Fix typo
2021-05-10 07:15:23 +00:00
hi-rustin
fc544abe03 Fix typo 2021-05-09 12:24:58 +08:00
Joshua Nelson
955fdaea4a Rename Parser::span_fatal_err -> Parser::span_err
The name was misleading, it wasn't actually a fatal error.
2021-05-08 23:11:59 -04:00
LeSeulArtichaut
cecb3be49a Improve diagnostics for functions in struct definitions 2021-05-07 21:44:10 +02:00
Aaron Hill
c6d67f8317
Add fast path when None delimiters are not involved 2021-04-12 17:26:26 -04:00
Aaron Hill
eb7b1a150f
Fix lookahead with None-delimited group 2021-04-12 11:50:16 -04:00
Aaron Hill
a93c4f05de
Implement token-based handling of attributes during expansion
This PR modifies the macro expansion infrastructure to handle attributes
in a fully token-based manner. As a result:

* Derives macros no longer lose spans when their input is modified
  by eager cfg-expansion. This is accomplished by performing eager
  cfg-expansion on the token stream that we pass to the derive
  proc-macro
* Inner attributes now preserve spans in all cases, including when we
  have multiple inner attributes in a row.

This is accomplished through the following changes:

* New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced.
  These are very similar to a normal `TokenTree`, but they also track
  the position of attributes and attribute targets within the stream.
  They are built when we collect tokens during parsing.
  An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when
  we invoke a macro.
* Token capturing and `LazyTokenStream` are modified to work with
  `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which
  is created during the parsing of a nested AST node to make the 'outer'
  AST node aware of the attributes and attribute target stored deeper in the token stream.
* When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`),
we tokenize and reparse our target, capturing additional information about the locations of
`#[cfg]` and `#[cfg_attr]` attributes at any depth within the target.
This is a performance optimization, allowing us to perform less work
in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-11 01:31:36 -04:00
Esteban Küber
0d7167698f Avoid ; -> , recovery and unclosed } recovery from being too verbose
Those two recovery attempts have a very bad interaction that causes too
unnecessary output. Add a simple gate to avoid interpreting a `;` as a
`,` when there are unclosed braces.
2021-04-09 10:22:41 -07:00
Aaron Hill
f94360fd83
Always preserve None-delimited groups in a captured TokenStream
Previously, we would silently remove any `None`-delimiters when
capturing a `TokenStream`, 'flattenting' them to their inner tokens.
This was not normally visible, since we usually have
`TokenKind::Interpolated` (which gets converted to a `None`-delimited
group during macro invocation) instead of an actual `None`-delimited
group.

However, there are a couple of cases where this becomes visible to
proc-macros:
1. A cross-crate `macro_rules!` macro has a `None`-delimited group
   stored in its body (as a result of being produced by another
   `macro_rules!` macro). The cross-crate `macro_rules!` invocation
   can then expand to an attribute macro invocation, which needs
   to be able to see the `None`-delimited group.
2. A proc-macro can invoke an attribute proc-macro with its re-collected
   input. If there are any nonterminals present in the input, they will
   get re-collected to `None`-delimited groups, which will then get
   captured as part of the attribute macro invocation.

Both of these cases are incredibly obscure, so there hopefully won't be
any breakage. This change will allow more agressive 'flattenting' of
nonterminals in #82608 without losing `None`-delimited groups.
2021-03-26 23:32:18 -04:00
Aaron Hill
7504b9bb96
Avoid double-collection for expression nonterminals 2021-03-25 18:05:49 -04:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Aaron Hill
fb5fec017b
Combine HasAttrs and HasTokens into AstLike
When token-based attribute handling is implemeneted in #80689,
we will need to access tokens from `HasAttrs` (to perform
cfg-stripping), and we will to access attributes from `HasTokens` (to
construct a `PreexpTokenStream`).

This PR merges the `HasAttrs` and `HasTokens` traits into a new
`AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec`
are removed - they aren't attribute targets, so the impls never really
made sense.
2021-02-27 00:14:13 -05:00
Dylan DPC
8e51bd4315
Rollup merge of #81235 - reese:rw-tuple-diagnostics, r=estebank
Improve suggestion for tuple struct pattern matching errors.

Closes #80174

This change allows numbers to be parsed as field names when pattern matching on structs, which allows us to provide better error messages when tuple structs are matched using a struct pattern.

r? ``@estebank``
2021-02-23 02:51:44 +01:00
Matthias Krüger
85bd00fd85 parser: remove unneccessary wrapping of return value in parse_extern() 2021-02-21 13:25:12 +01:00
mark
aee1e59e6f Simplify pattern grammar by allowing nested leading vert
Along the way, we also implement a handful of diagnostics improvements
and fixes, particularly with respect to the special handling of `||` in
place of `|` and when there are leading verts in function params, which
don't allow top-level or-patterns anyway.
2021-02-15 12:07:54 -06:00
Aaron Hill
3321d70161
Address review comments 2021-02-13 13:04:54 -05:00
Aaron Hill
0b411f56e1
Require passing an AttrWrapper to collect_tokens_trailing_token
This is a pure refactoring split out from #80689.
It represents the most invasive part of that PR, requiring changes in
every caller of `parse_outer_attributes`

In order to eagerly expand `#[cfg]` attributes while preserving the
original `TokenStream`, we need to know the range of tokens that
corresponds to every attribute target. This is accomplished by making
`parse_outer_attributes` return an opaque `AttrWrapper` struct. An
`AttrWrapper` must be converted to a plain `AttrVec` by passing it to
`collect_tokens_trailing_token`. This makes it difficult to accidentally
construct an AST node with attributes without calling `collect_tokens_trailing_token`,
since AST nodes store an `AttrVec`, not an `AttrWrapper`.

As a result, we now call `collect_tokens_trailing_token` for attribute
targets which only support inert attributes, such as generic arguments
and struct fields. Currently, the constructed `LazyTokenStream` is
simply discarded. Future PRs will record the token range corresponding
to the attribute target, allowing those tokens to be removed from an
enclosing `collect_tokens_trailing_token` call if necessary.
2021-02-13 12:07:15 -05:00
Aaron Hill
5d739180cd
Clone entire TokenCursor when collecting tokens
Reverts PR #80830
Fixes taiki-e/pin-project#312

We can have an arbitrary number of `None`-delimited group frames pushed
on the stack due to proc-macro invocations, which can legally be exited.
Attempting to account for this would add a lot of complexity for a tiny
performance gain, so let's just use the original strategy.
2021-01-28 09:47:59 -05:00
Vadim Petrochenkov
bd07165690 parser: Collect tokens for values in key-value attributes 2021-01-24 17:11:56 +03:00
bors
1986b58c64 Auto merge of #80065 - b-naber:parse-angle-arg-diagnostics, r=petrochenkov
Improve diagnostics when parsing angle args

https://github.com/rust-lang/rust/pull/79266 introduced parsing of generic arguments in associated type constraints, this however resulted in possibly very confusing error messages in cases in which closing angle brackets were missing such as in `Vec<(u32, _, _) = vec![]`, which outputs an incorrectly parsed equality constraint error, as noted by `@cynecx.`

This PR tries to provide better error messages in such cases.

r? `@petrochenkov`
2021-01-23 06:27:21 +00:00
b-naber
728d257839 improve diagnostics for angle args 2021-01-22 17:07:27 +01:00
Aaron Hill
ccfc292999
Refactor token collection to capture trailing token immediately 2021-01-22 00:33:03 -05:00
Reese Williams
8a83c8f64f Improve suggestion for tuple struct pattern matching errors.
Currently, when a user uses a struct pattern to pattern match on
a tuple struct, the errors we emit generally suggest adding fields
using their field names, which are numbers. However, numbers are
not valid identifiers, so the suggestions, which use the shorthand
notation, are not valid syntax. This commit changes those errors
to suggest using the actual tuple struct pattern syntax instead,
which is a more actionable suggestion.
2021-01-20 23:06:19 -05:00
Aaron Hill
11b1e37016
Force token collection to run when parsing nonterminals
Fixes #81007

Previously, we would fail to collect tokens in the proper place when
only builtin attributes were present. As a result, we would end up with
attribute tokens in the collected `TokenStream`, leading to duplication
when we attempted to prepend the attributes from the AST node.

We now explicitly track when token collection must be performed due to
nomterminal parsing.
2021-01-20 18:09:32 -05:00
Aaron Hill
a961e6785c
Set tokens on AST node in collect_tokens
A new `HasTokens` trait is introduced, which is used to move logic from
the callers of `collect_tokens` into the body of `collect_tokens`.

In addition to reducing duplication, this paves the way for PR #80689,
which needs to perform additional logic during token collection.
2021-01-13 22:10:36 -05:00
bors
f30733adb9 Auto merge of #80441 - petrochenkov:kwtok, r=Aaron1011
ast: Remove some indirection layers from values in key-value attributes

Trying to address some perf regressions from https://github.com/rust-lang/rust/pull/78837#issuecomment-745380762.
2021-01-09 22:19:46 +00:00
Vadim Petrochenkov
71cd6f42a6 ast: Remove some indirection layers from values in key-value attributes 2021-01-09 21:50:39 +03:00
Aaron Hill
7b36408b5f
Use an empty TokenCursorFrame stack when capturing tokens
We will never need to pop  past our starting frame during token
capturing. Using an empty stack allows us to avoid pointless heap
allocations/deallocations.
2021-01-08 18:16:20 -05:00
bors
44e3daf5ee Auto merge of #80459 - mark-i-m:or-pat-reg, r=petrochenkov
Implement edition-based macro :pat feature

This PR does two things:
1. Fixes the perf regression from https://github.com/rust-lang/rust/pull/80100#issuecomment-750893149
2. Implements `:pat2018` and `:pat2021` matchers, as described by `@joshtriplett`  in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090 behind the feature gate `edition_macro_pat`.

r? `@petrochenkov`

cc `@Mark-Simulacrum`
2020-12-31 14:52:26 +00:00
mark
40bf3c0f09 Implement edition-based macro pat feature 2020-12-30 09:57:49 -06:00
Yuki Okushi
4ae99cc843 Fix ICE when pointing at multi bytes character 2020-12-30 22:33:13 +09:00
mark
1a7d00a529 implement edition-specific :pat behavior for 2015/18 2020-12-19 07:13:36 -06:00
Aaron Hill
e6fa6334dd
Properly capture trailing 'unglued' token
If we try to capture the `Vec<u8>` in `Option<Vec<u8>>`, we'll
need to capture a `>` token which was 'unglued' from a `>>` token.
The processing of unglueing a token for parsing purposes bypasses the
usual capturing infrastructure, so we currently lose the trailing `>`.
As a result, we fall back to the reparsed `TokenStream`, causing us to
lose spans.

This commit makes token capturing keep track of a trailing 'unglued'
token. Note that we don't need to care about unglueing except at the end
of the captured tokens - if we capture both the first and second unglued
tokens, then we'll end up capturing the full 'glued' token, which
already works correctly.
2020-12-12 16:28:13 -05:00
Vadim Petrochenkov
31d72c2658 Accept arbitrary expressions in key-value attributes at parse time 2020-12-09 21:37:32 +03:00
Ryan Levick
823f64532c A slightly clearer diagnostic when misusing 2020-12-04 11:33:30 +01:00
Jonas Schievink
a732c3a369
Rollup merge of #78853 - calebcartwright:fix-const-block-expr-span, r=spastorino
rustc_parse: fix ConstBlock expr span

The span for a ConstBlock expression should presumably run through the end of the block it contains and not stop at the keyword, just like is done with similar block-containing expression kinds, such as a TryBlock
2020-11-28 15:58:15 +01:00
Aaron Hill
de88bf148b
Properly handle attributes on statements
We now collect tokens for the underlying node wrapped by `StmtKind`
instead of storing tokens directly in `Stmt`.

`LazyTokenStream` now supports capturing a trailing semicolon after it
is initially constructed. This allows us to avoid refactoring statement
parsing to wrap the parsing of the semicolon in `parse_tokens`.

Attributes on item statements
(e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as
item attributes, not statement attributes, which is consistent with how
we handle attributes on other kinds of statements. The feature-gating
code is adjusted so that proc-macro attributes are still allowed on item
statements on stable.

Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be
adjusted to support being passed `Annotatable::Stmt`.
2020-11-26 17:08:35 -05:00
Vadim Petrochenkov
2879ab793e rustc_parse: Remove optimization for 0-length streams in collect_tokens
The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare.
2020-11-12 22:00:48 +03:00
Caleb Cartwright
e1d5c3c054 fix(rustc_parse): ConstBlock expr span 2020-11-07 14:33:34 -06:00
Vadim Petrochenkov
d0c63bccc5 parser: Cleanup LazyTokenStream and avoid some clones
by using a named struct instead of a closure.
2020-10-31 01:56:34 +03:00
bors
20b1e05a8d Auto merge of #77502 - varkor:const-generics-suggest-enclosing-braces, r=petrochenkov
Suggest that expressions that look like const generic arguments should be enclosed in brackets

I pulled out the changes for const expressions from https://github.com/rust-lang/rust/pull/71592 (without the trait object diagnostic changes) and made some small changes; the implementation is `@estebank's.`

We're also going to want to make some changes separately to account for trait objects (they result in poor diagnostics, as is evident from one of the test cases here), such as an adaption of https://github.com/rust-lang/rust/pull/72273.

Fixes https://github.com/rust-lang/rust/issues/70753.

r? `@petrochenkov`
2020-10-27 09:25:54 +00:00
varkor
ac1454001c Suggest expressions that look like const generic arguments should be enclosed in brackets
Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-26 21:54:45 +00:00
bors
ffa2e7ae8f Auto merge of #77255 - Aaron1011:feature/collect-attr-tokens, r=petrochenkov
Unconditionally capture tokens for attributes.

This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.

We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.

This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.
2020-10-24 19:23:32 +00:00
Santiago Pastorino
83abed9df6
Make inline const work for half open ranges 2020-10-22 13:22:12 -03:00
Santiago Pastorino
954b5a81b4
Rename parse_const_expr to parse_const_block 2020-10-22 13:21:18 -03:00
Aaron Hill
920bed1213
Don't create an empty LazyTokenStream 2020-10-22 10:09:08 -04:00
bors
22e6b9c689 Auto merge of #77250 - Aaron1011:feature/flat-token-collection, r=petrochenkov
Rewrite `collect_tokens` implementations to use a flattened buffer

Instead of trying to collect tokens at each depth, we 'flatten' the
stream as we go allong, pushing open/close delimiters to our buffer
just like regular tokens. One capturing is complete, we reconstruct a
nested `TokenTree::Delimited` structure, producing a normal
`TokenStream`.

The reconstructed `TokenStream` is not created immediately - instead, it is
produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This
closure stores a clone of the original `TokenCursor`, plus a record of the
number of calls to `next()/next_desugared()`. This is sufficient to reconstruct
the tokenstream seen by the callback without storing any additional state. If
the tokenstream is never used (e.g. when a captured `macro_rules!` argument is
never passed to a proc macro), we never actually create a `TokenStream`.

This implementation has a number of advantages over the previous one:

* It is significantly simpler, with no edge cases around capturing the
  start/end of a delimited group.

* It can be easily extended to allow replacing tokens an an arbitrary
  'depth' by just using `Vec::splice` at the proper position. This is
  important for PR #76130, which requires us to track information about
  attributes along with tokens.

* The lazy approach to `TokenStream` construction allows us to easily
  parse an AST struct, and then decide after the fact whether we need a
  `TokenStream`. This will be useful when we start collecting tokens for
  `Attribute` - we can discard the `LazyTokenStream` if the parsed
  attribute doesn't need tokens (e.g. is a builtin attribute).

The performance impact seems to be neglibile (see
https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a
small slowdown on a few benchmarks, but it only rises above 1% for incremental
builds, where it represents a larger fraction of the much smaller instruction
count. There a ~1% speedup on a few other incremental benchmarks - my guess is
that the speedups and slowdowns will usually cancel out in practice.
2020-10-21 15:03:14 +00:00
Yuki Okushi
de24210ebf
Rollup merge of #78118 - spastorino:inline-const-followups, r=petrochenkov
Inline const followups

r? @petrochenkov

Follow ups of #77124
2020-10-21 13:59:44 +09:00
Santiago Pastorino
d641cb82c1
Allow NtBlock to parse on check inline const next token 2020-10-19 18:50:58 -03:00
Aaron Hill
593fdd3d45
Rewrite collect_tokens implementations to use a flattened buffer
Instead of trying to collect tokens at each depth, we 'flatten' the
stream as we go allong, pushing open/close delimiters to our buffer
just like regular tokens. One capturing is complete, we reconstruct a
nested `TokenTree::Delimited` structure, producing a normal
`TokenStream`.

The reconstructed `TokenStream` is not created immediately - instead, it is
produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This
closure stores a clone of the original `TokenCursor`, plus a record of the
number of calls to `next()/next_desugared()`. This is sufficient to reconstruct
the tokenstream seen by the callback without storing any additional state. If
the tokenstream is never used (e.g. when a captured `macro_rules!` argument is
never passed to a proc macro), we never actually create a `TokenStream`.

This implementation has a number of advantages over the previous one:

* It is significantly simpler, with no edge cases around capturing the
  start/end of a delimited group.

* It can be easily extended to allow replacing tokens an an arbitrary
  'depth' by just using `Vec::splice` at the proper position. This is
  important for PR #76130, which requires us to track information about
  attributes along with tokens.

* The lazy approach to `TokenStream` construction allows us to easily
  parse an AST struct, and then decide after the fact whether we need a
  `TokenStream`. This will be useful when we start collecting tokens for
  `Attribute` - we can discard the `LazyTokenStream` if the parsed
  attribute doesn't need tokens (e.g. is a builtin attribute).

The performance impact seems to be neglibile (see
https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a
small slowdown on a few benchmarks, but it only rises above 1% for incremental
builds, where it represents a larger fraction of the much smaller instruction
count. There a ~1% speedup on a few other incremental benchmarks - my guess is
that the speedups and slowdowns will usually cancel out in practice.
2020-10-19 13:59:18 -04:00
Aaron Hill
f6aec82d4d
Avoid cloning the contents of a TokenStream in a few places 2020-10-19 12:30:41 -04:00
Santiago Pastorino
c3e8d7965c
Parse inline const expressions 2020-10-16 15:15:30 -03:00
Esteban Küber
e5f83bcd04 Detect blocks that could be struct expr bodies
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:

```rust
fn foo() -> Foo {
    bar: Vec::new()
}
```

```
error[E0425]: cannot find value `bar` in this scope
 --> src/file.rs:5:5
  |
5 |     bar: Vec::new()
  |     ^^^ expecting a type here because of type ascription

error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
 --> src/file.rs:5:15
  |
5 |     bar: Vec::new()
  |               ^^^^^ only `Fn` traits may use parentheses

error[E0107]: wrong number of type arguments: expected 1, found 0
 --> src/file.rs:5:10
  |
5 |     bar: Vec::new()
  |          ^^^^^^^^^^ expected 1 type argument
  ```

If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:

```
error: struct literal body without path
 --> file.rs:4:17
  |
4 |   fn foo() -> Foo {
  |  _________________^
5 | |     bar: Vec::new(),
6 | | }
  | |_^
  |
help: you might have forgotten to add the struct literal inside the block
  |
4 | fn foo() -> Foo { Path {
5 |     bar: Vec::new(),
6 | } }
  |
```

Partially address last part of #34255.
2020-10-07 13:40:52 -07:00
Vadim Petrochenkov
219c66c55c rustc_parse: Make Parser::unexpected public and use it in built-in macros 2020-10-06 00:23:36 +03:00
Aurélien Deharbe
62068a59ee repairing broken error message and rustfix application for the new test
case
2020-09-11 17:31:52 +02:00
Aaron Hill
c1011165e6
Attach TokenStream to ast::Visibility
A `Visibility` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
2020-09-10 17:33:06 -04:00
Aleksey Kladov
ccf41dd5eb Rename IsJoint -> Spacing
To match better naming from proc-macro
2020-09-03 17:32:45 +02:00
bors
80fc9b0ecb Auto merge of #76160 - scileo:format-recovery, r=petrochenkov
Improve recovery on malformed format call

The token following a format expression should be a comma. However, when it is replaced with a similar token (such as a dot), then the corresponding error is emitted, but the token is treated as a comma, and the parsing step continues.

r? @petrochenkov
2020-09-02 19:29:27 +00:00
Sasha
3524c3ef43 Improve recovery on malformed format call
If a comma in a format call is replaced with a similar token, then we
emit an error and continue parsing, instead of stopping at this point.
2020-09-02 13:18:19 +02:00
Caleb Cartwright
883b1e7592 parser: restore some fn visibility for rustfmt 2020-08-30 13:04:36 -05:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00