| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
resolve: Make sure indeterminate and inconsistent macro resolutions always generate errors
Addresses the issue described in https://github.com/rust-lang/rust/pull/50911#issuecomment-392560525
I haven't come up with a minimized reproduction yet, but confirmed that `npbot` now generates the correct error with `![feature(use_extern_macros)]`.
|
|
generate errors
|
|
|
|
|
|
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
|
|
Fix typo in macro_parser.rs
innacurate -> inaccurate
|
|
|
|
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.
|
|
Point to the current box syntax tracking issue
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
r? @aidanhs
|
|
|
|
|
|
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
|
|
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
|
|
restore emplacement syntax (obsolete)
Fix https://github.com/rust-lang/rust/issues/50832
r? @petrochenkov
|
|
|
|
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.
|
|
2093 infer outlives requirements
Tracking issue: #44493
RFC: https://github.com/rust-lang/rfcs/pull/2093
- [x] add `rustc_attrs` flag
- [x] use `RequirePredicates` type
- [x] handle explicit predicates on `dyn` Trait
- [x] handle explicit predicates on projections
- [x] more tests
- [x] remove `unused`, `dead_code` and etc..
- [x] documentation
|
|
Add tests, documentation and attr for feature.
|
|
|
|
|
|
implement Ord for OutlivesPredicate and other types
It became necessary while implementing https://github.com/rust-lang/rust/pull/50070 to have `Ord` implemented for `OutlivesPredicate`.
This PR implements `Ord` for `OutlivesPredicate` as well as other types needed for the implementation.
|
|
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
|
|
|
|
impl Trait diagnostic/test cleanups
|
|
|
|
|
|
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
|
|
|
