Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use full expr span for return suggestion on type error/ambiguity #127129

Merged
merged 1 commit into from
Jul 1, 2024

Conversation

compiler-errors
Copy link
Member

We sometimes use parts of an expression rather than the whole thing for an obligation span. For example, a method obligation will just point to the path segment corresponding to the method in rcvr.method(args).

So let's not use that assuming it'll point to the whole expression span, which we can access from the expr hir id we store in ObligationCauseCode::WhereClauseInExpr.

Fixes #127109

@rustbot
Copy link
Collaborator

rustbot commented Jun 29, 2024

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 29, 2024
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The span changes LGTM, the UI test I believe has incorrect "follow-up error annotation" syntax (pre-existing, which may have led you astray).

if true {
Receiver.generic();
//~^ ERROR type annotations needed
//| HELP you might have meant to return this value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problem: I think this needs to be

Suggested change
//| HELP you might have meant to return this value
//~| HELP you might have meant to return this value

to quality as a "follow-up error annotation" in the UI test mode (and suite). Hm. Actually, is the HELP error annotation just wrong in that entire file? I dug through compiletest a little and

// Matches comments like:
// //~
// //~|
// //~^
// //~^^^^^
// //[rev1]~
// //[rev1,rev2]~^^

to the best of my knowledge //| is not a supported form of test annotation lol. Apparently there's a few other tests that also does the //| but AFAICT compiletest only uses the //~| form (cargo or r-a might be different here).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #127155 so I don't forgor about this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that was my typo from copypasting from the file without thinking rather than just writing my own UI test -- //| is definitely not valid and I should have seen that lmao

@jieyouxu
Copy link
Member

jieyouxu commented Jul 1, 2024

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 1, 2024
@compiler-errors
Copy link
Member Author

Made the test file less dumb

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 1, 2024
Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! r=me after CI is green.

@compiler-errors
Copy link
Member Author

@bors r=jieyouxu rollup

@bors
Copy link
Contributor

bors commented Jul 1, 2024

📌 Commit 583b5fc has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 1, 2024
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jul 1, 2024
…jieyouxu

Use full expr span for return suggestion on type error/ambiguity

We sometimes use parts of an expression rather than the whole thing for an obligation span. For example, a method obligation will just point to the path segment corresponding to the `method` in `rcvr.method(args)`.

So let's not use that assuming it'll point to the *whole* expression span, which we can access from the expr hir id we store in `ObligationCauseCode::WhereClauseInExpr`.

Fixes rust-lang#127109
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 1, 2024
…llaumeGomez

Rollup of 7 pull requests

Successful merges:

 - rust-lang#126753 (Add nightly style guide section for `precise_capturing` `use<>` syntax)
 - rust-lang#126880 (Migrate `volatile-intrinsics`, `weird-output-filenames`, `wasm-override-linker`, `wasm-exceptions-nostd` to `rmake`)
 - rust-lang#126941 (Migrate `run-make/llvm-ident` to `rmake.rs`)
 - rust-lang#127128 (Stabilize `duration_abs_diff`)
 - rust-lang#127129 (Use full expr span for return suggestion on type error/ambiguity)
 - rust-lang#127188 ( improve the way bootstrap handles rustlib components)
 - rust-lang#127201 (Improve run-make-support API)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 1, 2024
…llaumeGomez

Rollup of 8 pull requests

Successful merges:

 - rust-lang#126732 (Stabilize `PanicInfo::message()` and `PanicMessage`)
 - rust-lang#126753 (Add nightly style guide section for `precise_capturing` `use<>` syntax)
 - rust-lang#126832 (linker: Refactor interface for passing arguments to linker)
 - rust-lang#126880 (Migrate `volatile-intrinsics`, `weird-output-filenames`, `wasm-override-linker`, `wasm-exceptions-nostd` to `rmake`)
 - rust-lang#127128 (Stabilize `duration_abs_diff`)
 - rust-lang#127129 (Use full expr span for return suggestion on type error/ambiguity)
 - rust-lang#127188 ( improve the way bootstrap handles rustlib components)
 - rust-lang#127201 (Improve run-make-support API)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 61fe6b6 into rust-lang:master Jul 1, 2024
6 checks passed
@rustbot rustbot added this to the 1.81.0 milestone Jul 1, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jul 1, 2024
Rollup merge of rust-lang#127129 - compiler-errors:full-expr-span, r=jieyouxu

Use full expr span for return suggestion on type error/ambiguity

We sometimes use parts of an expression rather than the whole thing for an obligation span. For example, a method obligation will just point to the path segment corresponding to the `method` in `rcvr.method(args)`.

So let's not use that assuming it'll point to the *whole* expression span, which we can access from the expr hir id we store in `ObligationCauseCode::WhereClauseInExpr`.

Fixes rust-lang#127109
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rust suggests invalid syntax for returning a method call in E0282
5 participants