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

typeck: fix ? suggestion span #123654

Merged
merged 3 commits into from Apr 12, 2024
Merged

Conversation

jieyouxu
Copy link
Contributor

@jieyouxu jieyouxu commented Apr 8, 2024

Noticed in #112043 (comment), if the

use the `?` operator to extract the `Result<(), std::fmt::Error>` value, propagating a `Result::Err` value to the caller

suggestion is applied to a macro that comes from a non-local crate (e.g. the stdlib), the suggestion span can become non-local, which will cause newer rustfix versions to fail.

This PR tries to remedy the problem by recursively probing ancestors of the expression span, trying to identify the most ancestor span that is (1) still local, and (2) still shares the same syntax context as the expression.

This is the same strategy used in #112043.

The test unfortunately cannot //@ run-rustfix because there are two conflicting MaybeIncorrect suggestions that when collectively applied, cause the fixed source file to become non-compilable.

Also avoid running //@ run-rustfix for tests/ui/typeck/issue-112007-leaked-writeln-macro-internals.rs because that also contains conflicting suggestions.

cc @ehuss who noticed this. This question mark span fix + not running rustfix on the tests containing conflicting MaybeIncorrect suggestions should hopefully unblock rustfix from updating.

@rustbot
Copy link
Collaborator

rustbot commented Apr 8, 2024

r? @Nadrieril

rustbot has assigned @Nadrieril.
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 Apr 8, 2024
/// syntax context of a potential parent callsite changes, such as if the potential parent callsite
/// is in a foreign macro. This helps to prevent leaking implementation details from upstream
/// crates and stdlib crates that the user likely have no control over.
fn find_local_most_ancestor_suggestable_span(initial_span: Span) -> Span {
Copy link
Member

Choose a reason for hiding this comment

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

Why is this different than Span::find_ancestor_in_same_ctxt?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I see. We find the last ancestor that shares the ctxt, not the first. Huh.

Copy link
Contributor Author

@jieyouxu jieyouxu Apr 8, 2024

Choose a reason for hiding this comment

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

Yeah, it was to get better error reporting for when there are multiple local nested macros. TBH, I'm still not completely sure if this logic is robust for all the weird cases macros have...

Copy link
Contributor

Choose a reason for hiding this comment

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

This method should go in rustc_span, as a method on Span.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you have a better name for this? find_local_most_ancestor_suggestable_span is what I came up with but it feels not very accurate

Copy link
Member

Choose a reason for hiding this comment

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

How about find_oldest_ancestor_in_same_ctxt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds better than what I had 😆

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@jieyouxu
Copy link
Contributor Author

jieyouxu commented Apr 9, 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 Apr 9, 2024
@jieyouxu
Copy link
Contributor Author

jieyouxu commented Apr 9, 2024

(Ignored the doctest because it contains type errors for illustrative purposes)
@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 Apr 9, 2024
This can cause rustfix to crash because the `?` suggestion previously
could point into non-local spans, such as into the stdlib.
This test contains conflicting MaybeIncorrect suggestions which will
cause the fixed file to not compile.
@jieyouxu
Copy link
Contributor Author

Changed the method name to find_oldest_ancestor_in_same_ctxt and fixed its docs.

@Nadrieril
Copy link
Member

Looks good!

@bors r+

@bors
Copy link
Contributor

bors commented Apr 12, 2024

📌 Commit 420e3f1 has been approved by Nadrieril

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 Apr 12, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 12, 2024
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#123654 (typeck: fix `?` suggestion span)
 - rust-lang#123807 (Remove `sys_common::thread`)
 - rust-lang#123834 (Don't do coroutine-closure-specific upvar analysis if tainted by errors)
 - rust-lang#123847 (Suppress `let else` suggestion for uninitialized refutable `let`s)
 - rust-lang#123857 (std::net: TcpListener shrinks the backlog argument to 32 for Haiku.)
 - rust-lang#123858 (zkvm: fix path to cmath in zkvm module)
 - rust-lang#123867 (Add `unsafe` to two functions with safety invariants)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ca28e95 into rust-lang:master Apr 12, 2024
11 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Apr 12, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 12, 2024
Rollup merge of rust-lang#123654 - jieyouxu:question-mark-span, r=Nadrieril

typeck: fix `?` suggestion span

Noticed in <rust-lang#112043 (comment)>, if the

```
use the `?` operator to extract the `Result<(), std::fmt::Error>` value, propagating a `Result::Err` value to the caller
```

suggestion is applied to a macro that comes from a non-local crate (e.g. the stdlib), the suggestion span can become non-local, which will cause newer rustfix versions to fail.

This PR tries to remedy the problem by recursively probing ancestors of the expression span, trying to identify the most ancestor span that is (1) still local, and (2) still shares the same syntax context as the expression.

This is the same strategy used in rust-lang#112043.

The test unfortunately cannot `//@ run-rustfix` because there are two conflicting MaybeIncorrect suggestions that when collectively applied, cause the fixed source file to become non-compilable.

Also avoid running `//@ run-rustfix` for `tests/ui/typeck/issue-112007-leaked-writeln-macro-internals.rs` because that also contains conflicting suggestions.

cc `@ehuss` who noticed this. This question mark span fix + not running rustfix on the tests containing conflicting MaybeIncorrect suggestions should hopefully unblock rustfix from updating.
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.

None yet

7 participants