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

[WIP] borrowck diagnostic migration with eager booted #104941

Closed
wants to merge 1 commit into from

Conversation

AndyJado
Copy link
Contributor

on top of #104055

@rustbot
Copy link
Collaborator

rustbot commented Nov 26, 2022

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic 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 Nov 26, 2022
@AndyJado
Copy link
Contributor Author

r? @davidtwco

@rustbot rustbot assigned davidtwco and unassigned compiler-errors Nov 26, 2022
@bors

This comment was marked as resolved.

@bors

This comment was marked as resolved.

JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Jan 10, 2023
Support eager subdiagnostics again

See rust-lang#104941 (comment)

I'm not sure how to add a test for this. But I did pick some of the diagnostic structs in the mentioned PR and it works with them.
@davidtwco
Copy link
Member

I'll look at this after we land #104055

@davidtwco davidtwco added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 10, 2023
Noratrieb added a commit to Noratrieb/rust that referenced this pull request Jan 12, 2023
Support eager subdiagnostics again

See rust-lang#104941 (comment)

I'm not sure how to add a test for this. But I did pick some of the diagnostic structs in the mentioned PR and it works with them.
Noratrieb added a commit to Noratrieb/rust that referenced this pull request Jan 12, 2023
Support eager subdiagnostics again

See rust-lang#104941 (comment)

I'm not sure how to add a test for this. But I did pick some of the diagnostic structs in the mentioned PR and it works with them.
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Jan 13, 2023
Support eager subdiagnostics again

See rust-lang/rust#104941 (comment)

I'm not sure how to add a test for this. But I did pick some of the diagnostic structs in the mentioned PR and it works with them.
@bors

This comment was marked as resolved.

@bors

This comment was marked as resolved.

@AndyJado AndyJado marked this pull request as ready for review May 25, 2023 06:22
@bors

This comment was marked as resolved.

@rust-log-analyzer

This comment has been minimized.

@AndyJado AndyJado marked this pull request as draft May 26, 2023 10:16
@AndyJado
Copy link
Contributor Author

I'm back! I'll get the engine running in a few days.

@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@davidtwco I suppose this is a need eager on Diagonostic (not Subdiag) case, I've made all my attempts and I can't pass ui test,they are like whack-a-mole

@bors

This comment was marked as resolved.

@AndyJado AndyJado force-pushed the eager branch 2 times, most recently from 77e8f1b to 5fc91ad Compare November 2, 2023 13:32
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@davidtwco davidtwco left a comment

Choose a reason for hiding this comment

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

Left some more comments, you'll need to look at where the backticks are being added and make sure that we either only do them in the IntoDiagnosticArg implementations or in the Fluent messages.

debug!(
"report_mutability_error: item_msg and reason is moved to a struct due to diagnosing migration: [E0594] & [E0596], now they are typed value: {:?}",
&diagnostic
);
Copy link
Member

Choose a reason for hiding this comment

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

You don't need to keep these debug logs if they aren't necessary anymore.

@@ -1,9 +1,20 @@
// #![deny(rustc::untranslatable_diagnostic)]
// #![deny(rustc::diagnostic_outside_of_impl)]
Copy link
Member

Choose a reason for hiding this comment

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

This comment still seems relevant.

@@ -174,6 +186,10 @@ impl<'cx, 'tcx> MirBorrowckCtxt<'cx, 'tcx> {
}
}

pub(super) fn describe_place_typed(&self, place_ref: PlaceRef<'tcx>) -> DescribedPlace {
Copy link
Member

Choose a reason for hiding this comment

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

I presume this exists because changing describe_place to return a DescribedPlace` isn't practical?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

describe_place is used a lot, I'm currently narrowing the scope so it covers only PlaceAndReason cases.

fn into_diagnostic_arg(self) -> DiagnosticArgValue<'static> {
match self.0 {
Some(descr) => descr.into_diagnostic_arg(),
None => "value".into_diagnostic_arg(),
Copy link
Member

Choose a reason for hiding this comment

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

Maybe bug! here?

@@ -63,6 +63,18 @@ pub(super) struct DescribePlaceOpt {

pub(super) struct IncludingTupleField(pub(super) bool);

#[derive(Debug)]
pub(super) struct DescribedPlace(pub(super) Option<String>);
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 necessary if self.0 already implements IntoDiagnosticArg?

}
let name = ptr_source.describe_for_immutable_place(self.infcx.tcx);
diagnostic = PlaceAndReason::BehindPointer(
self.describe_place_typed(access_place.as_ref()),
Copy link
Member

Choose a reason for hiding this comment

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

Ah, so the "value" case in DescribedPlace is to handle the situation of "data" here?

@AndyJado
Copy link
Contributor Author

AndyJado commented Nov 7, 2023

I tracked function emit_diagnostic() and located where backticks are added, and my assumption is that it happens in some macro.

    fn emit_diagnostic(&mut self, diagnostic: &mut Diagnostic) -> Option<ErrorGuaranteed> {
        dbg!(&diagnostic.args().collect::<Vec<_>>());

I was runing a single UI test.

RUST_LOG=[emit_diagnostic] ./x.py test tests/ui/issues/issue-21600.rs

Here's the output diff:

+       [compiler/rustc_errors/src/lib.rs:1326] &diagnostic.args().collect::<Vec<_>>() = [
+           (
+               "place",
+               Str(
+                   "x",
+               ),
+           ),
+       ]
1       error[E0596]: cannot borrow `x` as mutable, as it is a captured variable in a `Fn` closure
2         --> $DIR/issue-21600.rs:14:20
3          |

10         |         |       in this closure
11         |         expects `Fn` instead of `FnMut`
12
-       error[E0596]: cannot borrow `x` as mutable, as it is a captured variable in a `Fn` closure
+       [compiler/rustc_errors/src/lib.rs:1326] &diagnostic.args().collect::<Vec<_>>() = []
+       [compiler/rustc_errors/src/lib.rs:1326] &diagnostic.args().collect::<Vec<_>>() = [
+           (
+               "place",
+               Str(
+                   "`x`",
+               ),
+           ),
+       ]
+       error[E0596]: cannot borrow ``x`` as mutable, as it is a captured variable in a `Fn` closure

@bors
Copy link
Contributor

bors commented Nov 26, 2023

☔ The latest upstream changes (presumably #118316) made this pull request unmergeable. Please resolve the merge conflicts.

@Dylan-DPC
Copy link
Member

@AndyJado any updates on this? thanks

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@AndyJado
Copy link
Contributor Author

AndyJado commented Feb 23, 2024

cannot_assign and cannot_borrow used to be string interpolation in one big function, after split them into structs E0594 and E0596, backtick repeats on some place description:

- error[E0596]: cannot borrow `r` as mutable
+ error[E0596]: cannot borrow ``r`` as mutable

I believe the answer lies in the macro implementation but I don't have the guts diving in. @Dylan-DPC


I'll keep conflict resolved.

@bors
Copy link
Contributor

bors commented Feb 28, 2024

☔ The latest upstream changes (presumably #121489) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Mar 8, 2024

☔ The latest upstream changes (presumably #122190) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
GITHUB_ACTION=__run_7
GITHUB_ACTIONS=true
GITHUB_ACTION_REF=
GITHUB_ACTION_REPOSITORY=
GITHUB_ACTOR=AndyJado
GITHUB_API_URL=https://api.github.com
GITHUB_BASE_REF=master
GITHUB_ENV=/home/runner/work/_temp/_runner_file_commands/set_env_2d9c9fb6-2530-44fc-a6c4-ad389920f053
GITHUB_EVENT_NAME=pull_request
---
GITHUB_SERVER_URL=https://github.com
GITHUB_SHA=2fd0b77025832c7006ee5c49548317a733185049
GITHUB_STATE=/home/runner/work/_temp/_runner_file_commands/save_state_2d9c9fb6-2530-44fc-a6c4-ad389920f053
GITHUB_STEP_SUMMARY=/home/runner/work/_temp/_runner_file_commands/step_summary_2d9c9fb6-2530-44fc-a6c4-ad389920f053
GITHUB_TRIGGERING_ACTOR=AndyJado
GITHUB_WORKFLOW_REF=rust-lang/rust/.github/workflows/ci.yml@refs/pull/104941/merge
GITHUB_WORKFLOW_SHA=2fd0b77025832c7006ee5c49548317a733185049
GITHUB_WORKSPACE=/home/runner/work/rust/rust
GOROOT_1_20_X64=/opt/hostedtoolcache/go/1.20.14/x64
---

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
   --> compiler/rustc_borrowck/src/diagnostics/mod.rs:611:17
    |
611 |             err.subdiagnostic(dcx, f(args_span));

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
   --> compiler/rustc_borrowck/src/diagnostics/mod.rs:628:25
    |
---

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
   --> compiler/rustc_borrowck/src/diagnostics/mod.rs:681:17
    |
681 |             err.subdiagnostic(dcx, diag);

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
    --> compiler/rustc_borrowck/src/diagnostics/mod.rs:1053:25
     |
     |
1053 |                     err.subdiagnostic(
     |                         ^^^^^^^^^^^^^

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
    --> compiler/rustc_borrowck/src/diagnostics/mod.rs:1062:25
     |
1062 |                     err.subdiagnostic(self.dcx(), CaptureReasonNote::FnOnceMoveInCall { var_span });

error: diagnostics should only be created in `IntoDiagnostic`/`AddToDiagnostic` impls
    --> compiler/rustc_borrowck/src/diagnostics/mod.rs:1066:25
     |

@bors
Copy link
Contributor

bors commented Mar 16, 2024

☔ The latest upstream changes (presumably #122571) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnCSimon
Copy link
Member

@AndyJado
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you are going to continue please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

@JohnCSimon JohnCSimon closed this May 26, 2024
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-translation Area: Translation infrastructure, and migrating existing diagnostics to SessionDiagnostic S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

9 participants