| Age | Commit message (Collapse) | Author | Lines |
|
To allow these braced macro invocation, this PR removes the optional expression from `ast::Block` and instead uses a `StmtKind::Expr` at the end of the statement list.
Currently, braced macro invocations in blocks can expand into statements (and items) except when they are last in a block, in which case they can only expand into expressions.
For example,
```rust
macro_rules! make_stmt {
() => { let x = 0; }
}
fn f() {
make_stmt! {} //< This is OK...
let x = 0; //< ... unless this line is commented out.
}
```
Fixes #34418.
|
|
Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`.
|
|
Refactor away `ast::Decl`, refactor `ast::Stmt`, and rename `ast::ExprKind::Again` to `ast::ExprKind::Continue`.
|
|
Miscellaneous low priority cleanup in `libsyntax`.
|
|
syntax-[breaking-change] cc #31645
(Only breaking because ast::TokenTree is now tokenstream::TokenTree.)
This pull request refactors TokenTrees into their own file as src/libsyntax/tokenstream.rs, moving them out of src/libsyntax/ast.rs, in order to prepare for an accompanying TokenStream implementation (per RFC 1566).
|
|
This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors). This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.
As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos). While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.
|
|
The AST part of https://github.com/rust-lang/rust/pull/34365
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645
|
|
**syntax-[breaking-change]** cc #31645
New `TraitItemKind::Macro` variant
This change adds support for macro expansion inside trait items by adding the new `TraitItemKind::Macro` and associated parsing code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Modified tests to point to the new file now.
|
|
|
|
|
|
|
|
|
|
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
|
|
Casual grepping revealed some places in the codebase (some of which
antedated `if let`'s December 2014 stabilization in c200ae5a) where we
were using a match with a `None => ()` arm where (in the present
author's opinion) an `if let` conditional would be more readable. (Other
places where matching to the unit value did seem to better express the
intent were left alone.)
It's likely that we don't care about making such trivial,
non-functional, sheerly æsthetic changes.
But if we do, this is a patch.
|
|
|
|
reference)
|
|
|
|
|
|
Rollup of 10 pull requests
- Successful merges: #33753, #33815, #33829, #33858, #33865, #33866, #33870, #33874, #33891, #33898
- Failed merges:
|
|
The AST part of https://github.com/rust-lang/rust/pull/33505.
https://github.com/rust-lang/rust/pull/33505 isn't landed yet, so this PR is based on top of it.
r? @nrc
plugin-[breaking-change] cc #31645 @Manishearth
|
|
cc https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645 @Manishearth
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes the "shadowing labels" warning *not* print the entire loop
as a span, but only the lifetime.
Also makes #31719 go away, but does not fix its root cause (the span
of the expanded loop is still wonky, but not used anymore).
|
|
Fix spans and expected token lists, fix #33413 + other cosmetic improvements
Add test for #33413
Convert between `Arg` and `ExplicitSelf` precisely
Simplify pretty-printing for methods
|
|
parser: do not try to continue with `unsafe` on foreign fns
The changed line makes it look like `unsafe` is allowed, but the first statement of `parse_item_foreign_fn` is:
```
self.expect_keyword(keywords::Fn)?;
```
So we get the strange "expected one of `fn`, `pub`, `static`, or `unsafe`, found `unsafe`".
Fixes: #27361
|
|
parser: show a helpful note on unexpected inner comment
Fixes: #30318.
|
|
parser: fix suppression of syntax errors in range RHS
Invalid expressions on the RHS were just swallowed without generating an error. The new version more closely mirrors the code for parsing `..x` in the `parse_prefix_range_expr` method below, where no cancel is done either.
Fixes #33262.
|
|
Add more aliases for Unicode confusable chars
Building upon #29837, this PR:
* added aliases for space characters,
* distinguished square brackets from parens, and
* added common CJK punctuation characters as aliases.
This will especially help CJK users who may have forgotten to switch off IME when coding.
|
|
Fixes: #30318.
|
|
parser: change warning into an error on `T<A=B, C>`
part of #32214
This seems to be the obvious fix, and the error message is consistent with all the other parser errors ("expected x, found y").
|
|
lexer: do not display char confusingly in error message
Current code leads to messages like `... use a \xHH escape: \u{e4}` which is confusing.
The printed span already points to the offending character, which should be enough to identify the non-ASCII problem.
Fixes: #29088
|
|
The extra filename and line was mainly there to keep the indentation
relative to the main snippet; now that this doesn't include
filename/line-number as a prefix, it is distracted.
|
|
Fixes: #32214
|
|
The changed line makes it look like `unsafe` is allowed, but the
first statement of `parse_item_foreign_fn` is:
`self.expect_keyword(keywords::Fn)?;`
So we get the strange "expected one of `fn`, `pub`, `static`, or
`unsafe`, found `unsafe`".
Fixes: #27361
|
|
Current code leads to messages like "... use a \xHH escape: \u{e4}"
which is confusing.
The printed span already points to the offending character, which
should be enough to identify the non-ASCII problem.
Fixes: #29088
|
|
Invalid expressions on the RHS were just swallowed without generating
an error. The new code more closely mirrors the code for parsing
`..x` in the `parse_prefix_range_expr` method, where no cancel is done
either.
Fixes #33262.
|
|
allow InternedString to be compared to &str directly
|
|
Parse `pub(restricted)` visibilities on tuple struct fields
Parse `pub(restricted)` on tuple struct fields (cc #32409).
r? @nikomatsakis
|