Change some notes into suggestions #42033

oli-obk · 2017-05-16T11:47:08Z

r? @petrochenkov since you commented on the same edits in #39458

petrochenkov · 2017-05-16T12:58:58Z

meta: It's hard to read diagnostic differences in a test if they are done in the same commit that turns the test from compile-fail to ui. Could you move all the compile-fail -> ui conversions into a separate commit?

petrochenkov · 2017-05-16T13:02:55Z

src/test/ui/issue-35675.stderr

+   |             ^^ not a type
+   |
+   = help: there is an enum variant `std::prelude::v1::Ok`,did you mean to use `std::prelude::v1`?
+   = help: there is an enum variant `std::prelude::v1::Result::Ok`,did you mean to use `std::prelude::v1::Result`?


IIRC, this test was moved to compile-fail due to instability in the order of suggestions (see #40775), so this will probably have to do be reverted, unless you want to fix the instability.

I'll fix the instability

petrochenkov · 2017-05-16T13:05:34Z

src/test/ui/resolve/issue-14254.stderr

@@ -2,7 +2,7 @@ error[E0425]: cannot find function `baz` in this scope
  --> $DIR/issue-14254.rs:29:9
   |
 29 |         baz();
-   |         ^^^ did you mean `self.baz(...)`?
+   |         ^^^ help: did you mean `self.baz`


Are the "did you mean" questions... rhetoric?
Is it ok to omit question marks in this context, linguistically?

The issue is that we have no idea whether the suggestion author wrote try or did you mean, so we can't generate a questionmark out of thin air. We could cover the common cases like did you mean, but have you tried won't get caught or any other textual changes

I think it's ok to add a heuristic catching "did you"/"have you" and appending the question mark.
All the messages are controlled by us after all, so they can always be tweaked if there are false positives/negatives.

(I'm assuming adding an extra argument to span_suggestion would be cumbersome, but it's a variant too.)

We could allow a placeholder in the message. So if you write did you mean {}? it will produce

did you mean `foobar`?

An in case it's not displayed inline, but as a help, the placeholder is replaced by "the following":

did you mean the following?

That would probably be the most convenient (I can live with a bit of home-grown formatting).

Ok. I implemented this, but the code complexity goes way up. I need to find the correct {}. I'll also need to allow {{ to escape opening brackets. I need to allow some way to specify a replacement like "the following", ....

How about my first variant suggested here?

add a new enum so the lint author can choose a message

enum SuggestionMsg { DidYouMean, Try, Custom { label: String, // msg to display as label help: String, // msg to display as help }, }

cc @nrc this touches on prepending help: before suggestions displayed as labels

I went through all suggestions' messages in rustc:

5 "did you mean {the following}"

"try casting to a reference instead:"

"try casting to a Box instead:"

"possible candidates found in another module, you can import them into scope:"

"did you mean to use the variant's enum"

"try adding parentheses:"

"try parenthesizing the first index"

"try placing this code inside a block"

"make this visible only to module {} with in:"

really long message about to_owned

"to access tuple elements, use"

"to force the closure to take ownership of {} (and any other referenced variables), use the move keyword, as shown"

"consider using a reference instead"

I don't see a good way to get all of these under one hat.

ISTM that the client should choose the punctuation here, which suggests that using {} is the best way. However, the extra complexity does seem a bit annoying. I think the current mix of template and free text is probably wrong - could we either allow totally free text or lock down the structure of the text more strictly (as an aside, I've never liked the "did you mean ..." phrasing, feels patronising, I'd prefer "you could try ...", but I don't care too much and this is a bit orthogonal.)

OK. I'll create a commit with the enum variant to see how it looks. Then we can reiterate.

bors · 2017-05-17T01:59:30Z

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

oli-obk · 2017-05-18T15:30:08Z

src/librustc_errors/diagnostic.rs

+    /// * should not contain any parts like "the following", "as shown"
+    /// * may look like "to do xyz, use" or "to do xyz, use abc"
+    /// * may contain a name of a function, variable or type, but not whole expressions
+    ///


I added some guidelines for suggestion messages. This way we can keep appending the suggestion at the end. I like this solution, because it's easy to read on the command line, requires little effort from suggestion authors and works well with non-label suggestions and json output.

petrochenkov · 2017-05-20T18:37:08Z

Is this ready for re-review?
Everything seems ok, but Travis is failing on UI test ui/cast-to-unsized-trait-object-suggestion.rs.

petrochenkov · 2017-05-20T18:38:33Z

src/test/ui-fulldeps/resolve-error.rs

@@ -35,46 +35,29 @@ macro_rules! attr_proc_mac {
 }

 #[derive(FooWithLongNan)]
-//~^ ERROR cannot find derive macro `FooWithLongNan` in this scope


I think it's better to keep these annotations.
UI and compile-fail tests are going to be unified and ERROR/WARN will be necessary again.

petrochenkov · 2017-05-20T18:44:42Z

cc @nrc this touches on prepending help: before suggestions displayed as labels

I'd vote for no "help: ", especially for messages for labels that previously didn't had it

oli-obk · 2017-05-22T13:00:27Z

Is this ready for re-review?

yes

Everything seems ok, but Travis is failing on UI test ui/cast-to-unsized-trait-object-suggestion.rs.

fixed

I think it's better to keep these annotations.
UI and compile-fail tests are going to be unified and ERROR/WARN will be necessary again.

done

I'd vote for no "help:", especially for messages for labels that previously didn't had it

As long as the message makes it clear that it's a suggestion... which all suggestions' messages should, but as discussed in the linked PR, this requires suggestion authors to take care when formulating the message.

petrochenkov · 2017-05-23T07:28:49Z

@bors r+

help: try: `x` looks horrible, though

bors · 2017-05-23T07:28:50Z

📌 Commit 72eb010 has been approved by petrochenkov

oli-obk · 2017-05-23T07:31:18Z

help: try: x looks horrible, though

I can create a PR that recognizes sentences starting with "try" or "you can try" and then leave out the "help:"

@petrochenkov

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

@petrochenkov

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

Mark-Simulacrum · 2017-05-24T01:49:14Z

I'm uncertain, but it looks like this caused the PR failure, but this is odd, since the checks here passed. It might be a conflict with another PR. Here's the relevant log: https://gist.github.com/Mark-Simulacrum/b5b140d6e27e99ace2598be544d6c405 which says that the file moved in this PR from compile-fail to ui tests failed UI testing. I haven't investigated beyond this.

@petrochenkov

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

oli-obk · 2017-06-28T06:45:29Z

I need a decision whether it's fine to completely refactor error reporting in resolve by storing all the errors in a table and report them after resolve is done.

petrochenkov · 2017-06-28T09:37:42Z

@oli-obk
Or you can move the problematic test from ui back into compile-fail.

oli-obk · 2017-06-28T10:34:04Z

I like fixing broken things. I'm sure this is not the only situation, just the only one we're testing. Also the paths reported are rather suboptimal, since no newcomer should have to see std::prelude::v1::...

bors · 2017-06-28T22:44:09Z

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

aidanhs · 2017-07-05T17:40:31Z

I'm going to mark this as being with the compiler team, cc @rust-lang/compiler, to get a response to

I need a decision whether it's fine to completely refactor error reporting in resolve by storing all the errors in a table and report them after resolve is done.

so this PR can progress in some way (either by moving the test back to compile-fail for this PR, or by going the proposed route, or something else).

arielb1 · 2017-07-11T10:54:58Z

Let's talk about this at the compiler meeting thursday?

The produced paths aren't stable between builds, since reporting paths inside resolve, before resolve is finished might produce paths resolved to type aliases instead of the concrete type. Compile-fail tests can match just parts of messages, so they don't "suffer" from this issue. This is just a workaround, the instability should be fixed in the future.

oli-obk · 2017-07-17T08:20:46Z

I moved the test back to compile-fail and will produce a new PR in the future to fix the instability.

petrochenkov · 2017-07-17T10:33:57Z

@bors r+

bors · 2017-07-17T10:33:58Z

📌 Commit eb7f429 has been approved by petrochenkov

bors · 2017-07-17T10:58:14Z

⌛ Testing commit eb7f429 with merge 5803f99...

@petrochenkov

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in #39458

nikomatsakis · 2017-07-17T12:32:14Z

src/test/ui/type-check/assignment-in-if.stderr

@@ -16,7 +16,7 @@ error[E0308]: mismatched types
 31 |     if (x = x) {
   |        ^^^^^^^
   |        |
-   |        help: did you mean to compare equality? `x == x`
+   |        help: did you mean to compare equality?: `x == x`


these look... funny to me now. I think it's just the juxtaposition of ? and :... can we end it with something like "did you mean to compare equality? Consider: x == x" instead?

Hm... those came in after a rebase. I'll create a new PR fixing up all suggestions that came in after I wrote the guidelines into the docs.

bors · 2017-07-17T13:31:28Z

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing 5803f99 to master...

Adjust new suggestions to the suggestion guidelines Addresses #42033 (comment) guidelines are https://github.com/rust-lang/rust/blob/master//src/librustc_errors/diagnostic.rs#L212-L224

@oli-obk

resolve: Try to fix instability in import suggestions cc #42033 `lookup_import_candidates` walks module graph in DFS order and skips modules that were already visited (which is correct because there can be cycles). However it means that if we visited `std::prelude::v1::Result::Ok` first, we will never visit `std::result::Result::Ok` because `Result` will be skipped as already visited (note: enums are also modules here), and otherwise, if we visited `std::result::Result::Ok` first, we will never get to `std::prelude::v1::Result::Ok`. What child module of `std` (`prelude` or `result`) we will visit first, depends on randomized hashing, so we have instability in diagnostics. With this patch modules' children are visited in stable order in `lookup_import_candidates`, this should fix the issue, but let's see what Travis will say. r? @oli-obk

rust-highfive assigned petrochenkov May 16, 2017

petrochenkov reviewed May 16, 2017

View reviewed changes

oli-obk force-pushed the suggestions branch 2 times, most recently from 3a5d066 to e1974c5 Compare May 18, 2017 15:27

oli-obk commented May 18, 2017

View reviewed changes

petrochenkov reviewed May 20, 2017

View reviewed changes

oli-obk force-pushed the suggestions branch from 1e853e0 to 6f681c2 Compare May 22, 2017 10:44

frewsxcv added a commit to frewsxcv/rust that referenced this pull request May 23, 2017

Rollup merge of rust-lang#42033 - oli-obk:suggestions, r=petrochenkov

5960da2

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

frewsxcv mentioned this pull request May 23, 2017

Rollup of 5 pull requests #42173

Closed

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request May 23, 2017

Rollup merge of rust-lang#42033 - oli-obk:suggestions, r=petrochenkov

c20a157

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

Mark-Simulacrum mentioned this pull request May 23, 2017

Rollup of 7 pull requests #42178

Closed

arielb1 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 23, 2017

frewsxcv added a commit to frewsxcv/rust that referenced this pull request May 24, 2017

Rollup merge of rust-lang#42033 - oli-obk:suggestions, r=petrochenkov

2fc3f28

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in rust-lang#39458

frewsxcv mentioned this pull request May 24, 2017

Rollup of 8 pull requests #42184

Closed

oli-obk added 3 commits July 17, 2017 08:38

Move some tests from compile-fail to ui

4a28663

Change some helps to suggestions

a9d9a4a

oli-obk force-pushed the suggestions branch from e8ebe80 to eb7f429 Compare July 17, 2017 08:20

bors added a commit that referenced this pull request Jul 17, 2017

Auto merge of #42033 - oli-obk:suggestions, r=petrochenkov

5803f99

Change some notes into suggestions r? @petrochenkov since you commented on the same edits in #39458

nikomatsakis reviewed Jul 17, 2017

View reviewed changes

carols10cents 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-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jul 17, 2017

bors merged commit eb7f429 into rust-lang:master Jul 17, 2017

bors mentioned this pull request Jul 17, 2017

Reorder span suggestions to appear below main labels #43251

Merged

oli-obk mentioned this pull request Jul 21, 2017

Adjust new suggestions to the suggestion guidelines #43386

Merged

oli-obk mentioned this pull request Jul 23, 2017

Point at : when using it instead of ; #43096

Merged

petrochenkov mentioned this pull request Jul 30, 2017

resolve: Try to fix instability in import suggestions #43552

Merged

Change some notes into suggestions #42033

Change some notes into suggestions #42033

Conversation

oli-obk commented May 16, 2017

petrochenkov commented May 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oli-obk May 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented May 17, 2017

Choose a reason for hiding this comment

petrochenkov commented May 20, 2017

Choose a reason for hiding this comment

petrochenkov commented May 20, 2017

oli-obk commented May 22, 2017

petrochenkov commented May 23, 2017

bors commented May 23, 2017

oli-obk commented May 23, 2017

Mark-Simulacrum commented May 24, 2017

oli-obk commented Jun 28, 2017

petrochenkov commented Jun 28, 2017

oli-obk commented Jun 28, 2017

bors commented Jun 28, 2017

aidanhs commented Jul 5, 2017

arielb1 commented Jul 11, 2017

oli-obk commented Jul 17, 2017

petrochenkov commented Jul 17, 2017

bors commented Jul 17, 2017

bors commented Jul 17, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Jul 17, 2017

oli-obk May 16, 2017 •

edited

Loading