| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It's so confusing to have everything having the same name, at least while refactoring.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=nikomatsakis
Fix processing mod with multi-level path on Windows
Fix error in [rustfmt](https://github.com/rust-lang-nursery/rustfmt/issues/1754) because libsyntax can not handle `mod` with multilevel path on Windows.
Alternative is do almost same in https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/fs.rs#L717 to allow work on paths with different separators, Ex. "\\\\?\\c:\\windows/temp"
|
|
Follow up to #51508, make parse_block public instead parse_block_expr
This is an follow up to #51508
I mistakenly made parse_block_expr public instead of parse_block.
This fixes this.
|
|
r=petrochenkov
refactor: create multiple HIR items for imports
When lowering `use` statements into HIR, they get a `Def` of the thing they're pointing at. This is great for things that need to know what was just pulled into scope. However, this is a bit misleading, because a `use` statement can pull things from multiple namespaces if their names collide. This is a problem for rustdoc, because if there are a module and a function with the same name (for example) then it will only document the module import, because that's that the lowered `use` statement points to.
The current version of this PR does the following:
* Whenever the resolver comes across a `use` statement, it loads the definitions into a new `import_map` instead of the existing `def_map`. This keeps the resolutions per-namespace so that all the target definitions are available.
* When lowering `use` statements, it looks up the resolutions in the `import_map` and creates multiple `Item`s if there is more than one resolution.
* To ensure the `NodeId`s are properly tracked in the lowered module, they need to be created in the AST, and pulled out as needed if multiple resolutions are available.
Fixes https://github.com/rust-lang/rust/issues/34843
|
|
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
|
|
public instead parse_block_expr
This is an follow up to #51508
I mistakenly made parse_block_expr public instead of parse_block.
This fixes this.
|
|
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
|
|
|
