Give correct suggestion for a typo in raw pointers #145903
Conversation
rustbot
added
S-waiting-on-review
| let allow_qpath_recovery = recover_qpath == RecoverQPath::Yes; | ||
| maybe_recover_from_interpolated_ty_qpath!(self, allow_qpath_recovery); | ||
|
|
||
| if (self.token.is_keyword(kw::Const) || self.token.is_keyword(kw::Mut)) |
There was a problem hiding this comment.
This probably should also be moved into a separate function and also moved way down into the actually if else chain below rather than being hit first on every call to parse_ty_common
There was a problem hiding this comment.
This was made exactly like attribute parsing in types right below, this why I originally chose this place and this strategy
About snapshoting I'm not fully sure I can and should use it here, not only because I fully know how and why it should be used, I checked other places where snapshotting was used and it mostly like in Err branch of match which I don't use
About eating Star it looks correct for me here even if we know that here is Star 100% beacuse we checked it in if, but if there any other way more better way to do I'm in full ears, but honestly I dont personally like this if branch here because of unreachable!, so yeah, should be a better way to do it,
I also adressed a wording problem, new one should be more straighforward and clear for end user
And I made a recovery as a TyKind::Ptr, agree that this is better generally
Also about lookahead(2) or can_begin_type I'm not quite sure why we need it, I'm parsing type in if with parse_ty_no_question_mark_recover to create a TyKind::Ptr from it, and if there will be no type at all it should fail earlier with a different error
compiler-errors
added
S-waiting-on-author
rust-cloud-vms
bot
force-pushed
the
c-style-pointer
branch
from
18a0d8e to
86b7749
Compare
|
@rustbot ready |
rustbot
added
S-waiting-on-review
rust-cloud-vms
bot
force-pushed
the
c-style-pointer
branch
from
86b7749 to
866fead
Compare
|
|
r? compiler |
rust-cloud-vms
bot
force-pushed
the
c-style-pointer
branch
from
866fead to
ea96b79
Compare
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
Rollup of 8 pull requests Successful merges: - #135099 (Add FileCheck annotations to mir-opt/copy-prop) - #145903 (Give correct suggestion for a typo in raw pointers) - #147520 (Port the remaining SIMD intrinsics to const-eval) - #148068 (rustdoc: Use configured target modifiers when collecting doctests) - #148099 (Prepare to move debugger discovery from compiletest to bootstrap) - #148268 (rustdoc: fix `--emit=dep-info` on scraped examples) - #148306 (Remove double check when decoding ExpnId to avoid races) - #148378 (Fix documentation for std::panic::update_hook) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #145903 - Kivooeo:c-style-pointer, r=davidtwco Give correct suggestion for a typo in raw pointers This adds a check for when user wrote `const* T` instead of `*const T`, I just saw how a C-person made this typo and compiler suggests this ```rust --> src/main.rs:2:17 | 2 | let p: const* u8 = 0 as _; | ^ | help: add `mut` or `const` here | 2 | let p: const*mut u8 = 0 as _; | +++ 2 | let p: const*const u8 = 0 as _; | +++++ ``` which is very incorrect also fixes #136602 r? compiler
Rollup of 8 pull requests Successful merges: - rust-lang/rust#135099 (Add FileCheck annotations to mir-opt/copy-prop) - rust-lang/rust#145903 (Give correct suggestion for a typo in raw pointers) - rust-lang/rust#147520 (Port the remaining SIMD intrinsics to const-eval) - rust-lang/rust#148068 (rustdoc: Use configured target modifiers when collecting doctests) - rust-lang/rust#148099 (Prepare to move debugger discovery from compiletest to bootstrap) - rust-lang/rust#148268 (rustdoc: fix `--emit=dep-info` on scraped examples) - rust-lang/rust#148306 (Remove double check when decoding ExpnId to avoid races) - rust-lang/rust#148378 (Fix documentation for std::panic::update_hook) r? `@ghost` `@rustbot` modify labels: rollup
7 participants
This adds a check for when user wrote
const* Tinstead of*const T, I just saw how a C-person made this typo and compiler suggests thiswhich is very incorrect
also fixes #136602
r? compiler