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

multiple substitutions become multiple children in JSON output #58221

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@zackmdavis
Copy link
Member

zackmdavis commented Feb 6, 2019

This is a proposed fix for #53934.

The problem being solved is this: in our internal representation of diagnostics, a CodeSuggestion can have one or more Substitutions, which can in turn have more than one SubstitutionParts. The vast majority of suggestions have just one Substitution and one SubstitutionPart, but .span_suggestions creates multiple Substitutions and .multipart_suggestion creates multiple SubstitutionParts.

Previously, the JSON-emitter was flat-mapping spans into the children field of serialized diagnostics, thereby conflating the one-substitution-with-multiple-parts case and the multiple-substitutions-with-one-part-each case, which tools like Rustfix need to be able to distinguish between. Here, we make multiple substitutions appear as multiple children, which is logical. Rustfix was already explicitly bailing out when it found multiple solutions, so there should be no breakage there. Breakage to RLS or third-party tooling may be possible, but is hoped/believed to be acceptable/within-policy (the intent here is to fix outright buggy output, not to constitute an incompatible change to the format).

Look specifically at the diff of the second "multiple substitutions become ..." commit to see the diff in the JSON output. (The first commit introduces some --error-format json UI tests specifically to document this.)

rust-lang-nursery/rustfix#162 is the sister pull-request for rustfix.

Don't merge this yet; the following items need to be resolved first—

  • ui/did_you_mean/issue-42764.rs specifically is failing for me locally, which I don't understand?? Presumably Travis will reproduce?
  • check that cargo fix can fix a multi-span substitution
  • look into how other tools cope with multiple substitutions being separate children

Thanks to @pietroalbini, @estebank, and @killercup for discussion at the 2019 All-Hands meeting.

r? @ghost (attempting to suppress bors autoassignment since this isn't ready yet)

zackmdavis added some commits Feb 6, 2019

add JSON error-format UI test expectations
This checks in a baseline so that it's easy to see the diff when we
change the output in a subsequent commit. These examples are from and
for #53934.
multiple substitutions become multiple children in JSON output
This is a proposed fix for #53934.

The problem being solved is this: in our internal representation of
diagnostics, a `CodeSuggestion` can have one or more `Substitutions`,
which can in turn have more than one `SubstitutionPart`s. The vast
majority of suggestions have just one `Substitution` and one
`SubstitutionPart`, but `.span_suggestions` creates multiple
`Substitutions` and `.multipart_suggestion` creates multiple
`SubstitutionParts`.

Previously, the JSON-emitter was flat-mapping spans into the
`children` field of serialized diagnostics, thereby conflating the
one-substitution-with-multiple-parts case and the
multiple-substitutions-with-one-part-each case, which tools like
Rustfix need to be able to distinguish between. Here, we make multiple
substitutions appear as multiple children, which is logical. Rustfix
was already explicitly bailing out when it found multiple solutions,
so there should be no breakage there. Breakage to RLS or third-party
tooling may be possible, but is hoped/believed to be
acceptable/within-policy (the intent here is to fix outright buggy
output, not to constitute an incompatible change to the format).

Thanks to Pietro Albini, Esteban Küber, and Pascal Hertleif for
discussion at the 2019 All-Hands meeting.
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Feb 6, 2019

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:58:39] .............................i...................................................................... 600/5371
[00:58:42] .................................................................................................... 700/5371
[00:58:47] .................................................................................................... 800/5371
[00:58:52] ............................................................................i...............i....... 900/5371
[00:58:55] .............................................................................................F...... 1000/5371
[00:58:59] ...iiiii............................................................................................ 1100/5371
[00:59:04] .................................................................................................... 1300/5371
[00:59:07] .................................................................................................... 1400/5371
[00:59:09] .................................................................................................... 1500/5371
[00:59:12] ..............................................................................................i..... 1600/5371
---
[01:01:27] error: /checkout/src/test/ui/did_you_mean/issue-42764.rs:11: unexpected help message: '11:43: 11:44: try using a variant of the expected type'
[01:01:27] 
[01:01:27] error: 1 unexpected errors found, 0 expected errors not found
[01:01:27] status: exit code: 1
[01:01:27] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/did_you_mean/issue-42764.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-42764/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/did_you_mean/issue-42764/auxiliary" "-A" "unused"
[01:01:27]     Error {
[01:01:27]         line_num: 11,
[01:01:27]         kind: Some(
[01:01:27]             Help
---
[01:01:27] 
[01:01:27] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:502:22
[01:01:27] 
[01:01:27] 
[01:01:27] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "ui" "--target" "x86_64-unknown-travis_time:end:0d6555ce:start=1549462016272574206,finish=1549465704630746780,duration=3688358172574
travis_time:start:30853a3a
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Wed Feb  6 15:08:24 UTC 2019
Wed, 06 Feb 2019 15:08:25 GMT

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@zackmdavis

This comment has been minimized.

Copy link
Member Author

zackmdavis commented Feb 6, 2019

Demonstration of cargo fix first failing to fix a multi-span substitution as of nightly, followed by it then succeeding with this patch and rust-lang-nursery/rustfix#162

multifix

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 7, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment