| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
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.
|
|
|
|
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.
|
|
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
|
|
span_fatal and parse_block were made private in #51265. These methods are used in stainless.
Related #51498 #51504
|
|
|
|
|
|
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
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
to Plus token.
|
|
|
|
This commit is concerned with the case where the user tries to mutably
borrow a mutable reference, thereby triggering an error. Instead of the
existing suggestion to make the binding mutable, the compiler will now
suggest to avoid borrowing altogether.
|
|
|
|
|
|
Two minor parsing tweaks
|
|
|
|
By calling `bump()` after getting the first char, to avoid a redundant
`ident_continue()` test on it.
|
|
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
r? @Manishearth
cc @killercup @estebank
|
|
estebank:and_the_case_of_the_confusable_float_exponent, r=eddyb
Check for confusable Unicode chars in float literal exponent
Fixing tests for #49989. Resolves #49746.
|
|
|
|
Use `Ident`s for fields in HIR
Continuation of https://github.com/rust-lang/rust/pull/49718, part of https://github.com/rust-lang/rust/issues/49300
|
|
|
|
The `FatalError.raise()` might seem unmotivated (in most places in
the compiler, `err.emit()` suffices), but it's actually used to
maintain behavior (viz., stop lexing, don't emit potentially spurious
errors looking for the next token after the bad Unicodepoint in the
exponent): the previous revision's `self.err_span_` ultimately calls
`Handler::emit`, which aborts if the `Handler`'s continue_after_error
flag is set, which seems to typically be true during lexing (see
`phase_1_parse_input` and and how `CompileController::basic` has
`continue_parse_after_error: false` in librustc_driver).
Also, let's avoid apostrophes in error messages (the present author
would argue that users expect a reassuringly detached, formal,
above-it-all tone from a Serious tool like a compiler), and use an
RLS-friendly structured suggestion.
Resolves #49746.
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #50864 (Add NetBSD/arm target specs)
- #50956 (rust-gdb: work around the re-used -d argument in cgdb)
- #50964 (Make sure that queries have predictable symbol names.)
- #50965 (Update LLVM to pull in another wasm fix)
- #50972 (Add -Z no-parallel-llvm flag)
- #50979 (Fix span for type-only arguments)
- #50981 (Shrink `LiveNode`.)
- #50995 (move type out of unsafe block)
- #51011 ( rustdoc: hide macro export statements from docs)
Failed merges:
|
|
Fix span for type-only arguments
Currently it points to the comma or parenthesis before the type, which is broken
cc @mark-i-m this is what broke #48309
r? @estebank
|
|
rustc: Correctly pretty-print macro delimiters
This commit updates the `Mac_` AST structure to keep track of the delimiters
that it originally had for its invocation. This allows us to faithfully
pretty-print macro invocations not using parentheses (e.g. `vec![...]`). This in
turn helps procedural macros due to #43081.
Closes #50840
|
|
|
|
|
|
This commit updates the `Mac_` AST structure to keep track of the delimiters
that it originally had for its invocation. This allows us to faithfully
pretty-print macro invocations not using parentheses (e.g. `vec![...]`). This in
turn helps procedural macros due to #43081.
Closes #50840
|
|
rustc: Fix procedural macros generating lifetime tokens
This commit fixes an accidental regression from #50473 where lifetime tokens
produced by procedural macros ended up getting lost in translation in the
compiler and not actually producing parseable code. The issue lies in the fact
that a lifetime's `Ident` is prefixed with `'`. The `glue` implementation for
gluing joint tokens together forgot to take this into account so the lifetime
inside of `Ident` was missing the leading tick!
The `glue` implementation here is updated to create a new `Symbol` in these
situations to manufacture a new `Ident` with a leading tick to ensure it parses
correctly.
Closes #50942
|
|
Issue #50636: Improve error diagnostic with missing commas after struct fields.
Fixes #50636
|
|
rustc: Fix joint-ness of stringified token-streams
This commit fixes `StringReader`'s parsing of tokens which have been stringified
through procedural macros. Whether or not a token tree is joint is defined by
span information, but when working with procedural macros these spans are often
dummy and/or overridden which means that they end up considering all operators
joint if they can!
The fix here is to track the raw source span as opposed to the overridden span.
With this information we can more accurately classify `Punct` structs as either
joint or not.
Closes #50700
|
|
This commit fixes an accidental regression from #50473 where lifetime tokens
produced by procedural macros ended up getting lost in translation in the
compiler and not actually producing parseable code. The issue lies in the fact
that a lifetime's `Ident` is prefixed with `'`. The `glue` implementation for
gluing joint tokens together forgot to take this into account so the lifetime
inside of `Ident` was missing the leading tick!
The `glue` implementation here is updated to create a new `Symbol` in these
situations to manufacture a new `Ident` with a leading tick to ensure it parses
correctly.
Closes #50942
|
