| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Stabilize #[repr(transparent)]
Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318
Reference PR: https://github.com/rust-lang-nursery/reference/pull/353
|
|
Add error message for using >= 65535 hashes for raw string literal escapes
Fixes #50111.
|
|
Rollup of 3 pull requests
Successful merges:
- #51261 (Updated RELEASES.md for 1.27.0)
- #51502 (Make parse_seq_to_end and parse_path public)
- #51510 (Long diagnostic for E0538)
Failed merges:
|
|
Long diagnostic for E0538
r? @GuillaumeGomez
|
|
Make parse_seq_to_end and parse_path public
(see SergioBenitez/Rocket#660, rust-lang/rust#51265)
Rocket currently uses `parse_seq_to_end` and `parse_path` in its codegen macros. Assuming I tested correctly, this is the minimal set of methods that are currently necessary to build Rocket again. I would be happy to add documentation of this and Rocket's other usages, if desired.
|
|
Fix for $crate var normalization in proc macro for externally defined macros
Fixes #51331, a bug that has existed in at least *some* form for a year and a half.
The PR includes the addition of a `fold_qpath` method to `syntax::fold::Folder`. Overriding this method is useful for folds that modify paths in a way that invalidates indices (insertion or removal of a component), as it provides the opportunity to update `qself.position` in `<A as B>::C` paths. I added it because the bugfix is messy without it.
(unfortunately, grepping around the codebase, I did not see anything else that could use it.)
|
|
|
|
Make span_fatal and parse_block public
span_fatal and parse_block were made private in #51265. These methods are used in stainless.
Related #51498 #51504
|
|
Tracking issue FCP: https://github.com/rust-lang/rust/issues/43036#issuecomment-394094318
Reference PR: https://github.com/rust-lang-nursery/reference/pull/353
|
|
Make parse_ident public
`parse_ident` was made private in #51265. In rustfmt the method is used to create a custom parser for macro call.
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/27389
|
|
span_fatal and parse_block were made private in #51265. These methods are used in stainless.
Related #51498 #51504
|
|
|
|
Long diagnostic for E0541
r? @GuillaumeGomez
|
|
|
|
|
|
Enable fall through past $:lifetime matcher
```rust
macro_rules! is_lifetime {
($lifetime:lifetime) => { true };
($other:tt) => { false };
}
fn main() {
println!("{}", is_lifetime!('lifetime));
println!("{}", is_lifetime!(@));
}
```
Before this fix, the `is_lifetime!` invocation would fail to compile with:
```
error: expected a lifetime, found `@`
--> src/main.rs:8:33
|
8 | println!("{}", is_lifetime!(@));
| ^
```
Fixes #50903.
Fixes #51477.
r? @kennytm
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Include parens to type parameter
The motivation of this PR is to fix a bug in rustfmt (cc https://github.com/rust-lang-nursery/rustfmt/issues/2630).
|
|
|
|
|
|
|
|
parser: Split `+=` into `+` and `=` where `+` is explicitly requested (such as generics)
Added functions in tokens to check whether a token leads with `+`. Used them when parsing to allow for token splitting of `+=` into `+` and `=`.
Fixes https://github.com/rust-lang/rust/issues/47856
|
|
Stabilize unit tests with non-`()` return type
References #48854
|
|
Fix Issue 38777
When looking through for a closing bracket in the loop condition, adds them to expecteds.
https://github.com/rust-lang/rust/issues/38777
|
|
|
|
Revert #49719
This also needs to be backported into beta.
Fixes #51416.
r? @nikomatsakis
|
|
kennytm:fix-51279-preempt-the-warning-song-and-dance, r=nikomatsakis
Deny #[cfg] and #[cfg_attr] on generic parameters.
Fix #51279.
Attributes on generic parameters are not expanded, meaning `#[cfg]`, `#[cfg_attr]` and attribute proc macros are entirely ignored on them.
This PR makes using the first two attributes an error, because if they are correctly expanded will affect the AST and change code behavior.
I'm beta-nominating this, because generic parameter attributes are stabilizing in 1.27, and if we did not reserve their usage, we may never be able to repurpose the meaning of these attributes in the Rust 2015 edition.
|
|
This reverts commit d6ba1b9b021c408fcad60ee52acf8af5e1b2eb00, reversing
changes made to 8de5353f75dcde04abe947e0560dc5edd861cf3a.
|
|
Accept `..` in incorrect position to avoid further errors
We currently give a specific message when encountering a `..` anywhere
other than the end of a pattern. Modify the parser to accept it (while
still emitting the error) so that we don't also trigger "missing fields
in pattern" errors afterwards.
Add suggestions to either remove trailing `,` or moving the `..` to the
end.
Follow up to #49268.
|
|
|
|
|
|
|
|
|
|
When using `..` somewhere other than the end, parse the rest of the
pattern correctly while still emitting an error.
Add suggestions to either remove trailing `,` or moving the `..` to the
end.
|
|
We currently give a specific message when encountering a `..` anywhere
other than the end of a pattern. Modify the parser to accept it (while
still emitting the error) so that we don't also trigger "missing fields
in pattern" errors afterwards.
|
|
rustdoc: introduce the #[doc(keyword="")] attribute for documenting keywords
Part of #34601.
r? @QuietMisdreavus
|
|
|
|
|
|
|
|
to Plus token.
|
|
|
|
Suggest not mutably borrowing a mutable reference
This PR would (hopefully) solve #45392. I deviated a bit from @estebank's instructions since the error span only included the borrowed expression (e.g. the `b` in `&mut b`). I also didn't check the mutability of the local binding, since this whole case is concerned with an immutable local.
I can see two outstanding questions:
1. `note_immutability_blame` is called in two places, but I only have one test case. I think it covers the call in `report_bckerror`, but I'm not sure how to trigger the call from `report_aliasability_violation`.
2. There is one failing test, where the local binding is `self: &mut Self`. I'm not entirely sure what the correct output should be, but I think the new message should also apply. Unfortunately, since this parameter is parsed differently, its `let_span` covers both the pattern and the type, leading to a wrong suggestion text. I'm not sure how to correctly identify this case.
|
|
|
|
|
