rust/src/librustc_parse/parser, branch master

mv compiler to compiler/

2020-08-30T15:45:07+00:00

Use smaller def span for functions

2020-08-22T22:41:49+00:00

Currently, the def span of a funtion encompasses the entire function signature and body. However, this is usually unnecessarily verbose - when we are pointing at an entire function in a diagnostic, we almost always want to point at the signature. The actual contents of the body tends to be irrelevant to the diagnostic we are emitting, and just takes up additional screen space. This commit changes the `def_span` of all function items (freestanding functions, `impl`-block methods, and `trait`-block methods) to be the span of the signature. For example, the function ```rust pub fn foo(val: T) -> T { val } ``` now has a `def_span` corresponding to `pub fn foo(val: T) -> T` (everything before the opening curly brace). Trait methods without a body have a `def_span` which includes the trailing semicolon. For example: ```rust trait Foo { fn bar(); }``` the function definition `Foo::bar` has a `def_span` of `fn bar();` This makes our diagnostic output much shorter, and emphasizes information that is relevant to whatever diagnostic we are reporting. We continue to use the full span (including the body) in a few of places: * MIR building uses the full span when building source scopes. * 'Outlives suggestions' use the full span to sort the diagnostics being emitted. * The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]` attribute points the entire scope body. * The 'unconditional recursion' lint uses the full span to show additional context for the recursive call. All of these cases work only with local items, so we don't need to add anything extra to crate metadata.

Auto merge of #74566 - lzutao:guard, r=petrochenkov

2020-08-22T15:38:13+00:00

Gate if-let guard feature Enhanced on #74315. That PR is in crater queue so I don't want to push to it. Close #74232 cc #51114

Capture tokens for Pat used in macro_rules! argument

2020-08-20T06:45:28+00:00

This extends PR #73293 to handle patterns (Pat). Unlike expressions, patterns do not support custom attributes, so we only need to capture tokens during macro_rules! argument parsing.

Rollup merge of #75658 - tgnottingham:issue-75599, r=estebank

2020-08-19T06:54:35+00:00

Don't emit "is not a logical operator" error outside of associative expressions Avoid showing this error where it doesn't make sense by not assuming "and" and "or" were intended to mean "&&" and "||" until after we decide to continue parsing input as an associative expression. Note that the decision of whether or not to continue parsing input as an associative expression doesn't actually depend on this assumption. Fixes #75599 --- First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)

Don't emit "is not a logical operator" error outside of associative expressions

2020-08-18T19:15:57+00:00

Avoid showing this error where it doesn't make sense by not assuming "and" and "or" were intended to mean "&&" and "||" until after we decide to continue parsing input as an associative expression. Note that the decision of whether or not to continue parsing input as an associative expression doesn't actually depend on this assumption. Fixes #75599

rust_ast::ast => rustc_ast

2020-08-17T20:32:32+00:00

replaced log with tracing

2020-08-15T20:03:11+00:00

Rollup merge of #75513 - estebank:confused-parser, r=davidtwco

2020-08-15T03:07:13+00:00

Recover gracefully from `struct` parse errors Currently the parser tries to recover from finding a keyword where a field name was expected, but this causes extra knock down parse errors that are completely irrelevant. Instead, bail out early in the parsing of the field and consume the remaining tokens in the block. This can reduce output significantly. _Improvements based on the narrative in https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust_

Recover gracefully from `struct ` parse errors

2020-08-14T04:15:36+00:00