| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Followup on #28440
Do not merge before the referenced PR is merged. I will fix the PR once that is merged (or close if it is not)
|
|
|
|
|
|
Temporary 'fix' for #26775
|
|
|
|
|
|
|
|
Followup on #28440
|
|
fixes #28433
|
|
|
|
This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.
|
|
The second commit in this PR will stop printing the macro definition site in backtraces, which cuts their length in half and increases readability (the definition site was only correct for local macros).
The third commit will not print an invocation if the last one printed occurred at the same place (span). This will make backtraces caused by a self-recursive macro much shorter.
(A possible alternative would be to capture the backtrace first, then limit it to a few frames at the start and end of the chain and print `...` inbetween. This would also work with multiple macros calling each other, which is not addressed by this PR - although the backtrace will still be halved)
Example:
```rust
macro_rules! m {
( 0 $($t:tt)* ) => ( m!($($t)*); );
() => ( fn main() {0} );
}
m!(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0);
```
On a semi-recent nightly, this yields:
```
test.rs:3:21: 3:22 error: mismatched types:
expected `()`,
found `_`
(expected (),
found integral variable) [E0308]
test.rs:3 () => ( fn main() {0} );
^
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:6:1: 6:35 note: expansion site
test.rs:3:21: 3:22 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
```
After this patch:
```
test.rs:3:21: 3:22 error: mismatched types:
expected `()`,
found `_`
(expected (),
found integral variable) [E0308]
test.rs:3 () => ( fn main() {0} );
^
test.rs:2:23: 2:34 note: in this expansion of m!
test.rs:6:1: 6:35 note: in this expansion of m!
test.rs:3:21: 3:22 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
```
|
|
as per #28243.
|
|
|
|
|
|
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
|
|
|
