| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This allows to skip the codegen for all the unneeded landing pads, reducing code size across the board by about 2-5%, depending on the crate. Compile times seem to be pretty unaffected though :-/
|
|
|
|
There is a dead code in libsyntax/parser/parse.rs, when parsing structs.
Two functions are involved:
* [parse_item_struct](https://github.com/rust-lang/rust/blob/cd9c9f048f6aa0be091cd9835771ba0712bead4e/src/libsyntax/parse/parser.rs#L4691)
* [parse_tuple_struct_body](https://github.com/rust-lang/rust/blob/cd9c9f048f6aa0be091cd9835771ba0712bead4e/src/libsyntax/parse/parser.rs#L4769)
The problem is that both functions handle the case with unit structs. But because
`parse_tuple_struct_body` is called from `parse_item_struct`, it never faces
this case.
This PR removes unit struct case from `parse_tuple_struct_body` function. I tested with `make -j8 check-statge1`.
|
|
|
|
|
|
This halves the backtrace length. The definition site wasn't very useful
anyways, since it may be invalid (for compiler expansions) or located in
another crate. Since the macro name is still printed, grepping for it is
still an easy way of finding the definition.
|
|
|
|
Escape `{` in format strings as `{{`, instead of using a substitution
|
|
|
|
|
|
This is similar to the libs version, which allow an `issue` field in the
`#[unstable]` attribute.
cc #28244
|
|
This is similar to the libs version, which allow an `issue` field in the
`#[unstable]` attribute.
cc #28244
|
|
|
|
Both `parse_tuple_struct_body` and `parse_item_struct` handled the case
of unit like struct. The redundancy is removed,
`parse_tuple_struct_body` now handles only real tuple structs.
|
|
per #28168. This is my first contribution. I don't know who to "r?" for source code changes.
|
|
|
|
|
|
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
Closes #28032
|
|
This commit is an implementation of [RFC 1212][rfc] which tweaks the behavior of
the `str::lines` and `BufRead::lines` iterators. Both iterators now account for
`\r\n` sequences in addition to `\n`, allowing for less surprising behavior
across platforms (especially in the `BufRead` case). Splitting *only* on the
`\n` character can still be achieved with `split('\n')` in both cases.
The `str::lines_any` function is also now deprecated as `str::lines` is a
drop-in replacement for it.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md
Closes #28032
|
|
r? @alexcrichton
|
|
Avoid confusion with binary integer literals and binary operator expressions in libsyntax
|
|
Fixes #28109
|
|
r? @nikomatsakis
Trying to land this first stab, which basically just duplicates the AST. Will file issues for the various things I've got in mind to improve.
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/28108.
|
|
The spans of break and continue would include the next token.
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
This is a [breaking-change] for syntax extension authors. The fix is to use MultiModifier or MultiDecorator, which have the same functionality but are more flexible. Users of syntax extensions are unaffected.
|
|
|
|
There is no longer a need for that pattern, since enums are now qualified.
|
|
Fixes https://github.com/rust-lang/rust/issues/28105.
|
|
Fixes https://github.com/rust-lang/rust/issues/28105.
|
|
|
|
This allows marking attributes as whitelisted/crate-only independent of
their feature gate status.
Closes #24213
|
|
|
|
This allows marking attributes as whitelisted/crate-only independent of
their feature gate status.
Closes #24213
|
|
We were using them for every expansion, instead of using `Name`.
Also converted `CompilerExpansion` into an enum so its nicer to use and takes up less space.
Will profile later, but this should be a small improvement in memory usage.
r? @eddyb
|
|
|
|
|
|
There is no longer a need for that pattern, since enums are now qualified.
|
|
Fixes #11766.
|
|
This handles the case where the #[main] function is buried deeper in
the ast than we search for #[test] functions. I'm not sure why one
would want to do that, but since it works in standard compilation it
should also work for tests.
|
|
Fixes #12327.
|
|
Identifying entry points will be useful in --test mode, which is
handled in libsyntax.
|
|
closes #19102
|
|
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
|
|
|
|
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
I hope this is ok to do, since all of rustc is considered unstable...
|
|
In the case where there are no paren in the AST, the pretty printer doesn't correctly print binary operations where precedence is concerned. Parenthesis may be missing due to some kind of expansion or manipulation of the AST.
Example:
Pretty printer prints Expr(*, Expr(+, 1, 1), 2) as 1 + 1 * 2, as opposed to (1 + 1) * 2
r? @nrc
|
