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

Add -Z teach flag to provide extended diagnostic help #47652

Merged
merged 10 commits into from
Jan 26, 2018

Conversation

estebank
Copy link
Contributor

First step to have a way for the compiler to provide as much information as the --explain E0XXX flag does, but providing the text in the context of the users' code.

r? @nikomatsakis

@estebank
Copy link
Contributor Author

screen shot 2018-01-21 at 21 39 05

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 22, 2018
@nikomatsakis
Copy link
Contributor

Maybe we need a different name (for back-compat).

Here are some synonyms:

--expound, --say-more, --details, --teach, --elucidate

I think I like --teach.

@nikomatsakis
Copy link
Contributor

Also, long term, do you envision us having this text etc in the code like this, or separated into some form of "template"?

@estebank
Copy link
Contributor Author

At the very least I would separate the place where the error is being emitted from the error being prepared for presentation. Using a template is a good possibility, but I feel it can be approached independently from the introduction of the flag.

The way to use it now is rustc -Z unstable-options -Z explain file.rs. I feel that using the same flag shouldn't as now shouldn't be a problem, as in both cases the intention is the same, give me more context on what I'm seeing. Also, the content should be, of not the same, equivalent for both, to the point where explain E0XXX should look like diagnostic output too.

@estebank
Copy link
Contributor Author

Having said that, teach is a nice option.

@nikomatsakis
Copy link
Contributor

At the very least I would separate the place where the error is being emitted from the error being prepared for presentation. Using a template is a good possibility, but I feel it can be approached independently from the introduction of the flag.

Yes, it can be, I just wanted to clarify. In particular, I don't know whether we will want to be writing a lot of such explanations in this style, or whether we'd prefer to sketch out how a template would look.

Personally, I think we should move towards a templating engine, but I am also appreciate of the fact that it'd be nice to get started now and not block on things.

The way to use it now is rustc -Z unstable-options -Z explain file.rs

First off, you should not need -Zunstable-options, -Z itself already implies unstable.

This is also why I don't think we should use -Zexplain -- because, once we stabilize, we are going to want a stable name, and --explain is already taken. (Unless we want to make it something like --explain all, but I'd rather just deprecate --explain entirely.)

(Hmm, I suppose we could move towards a model where --explain E123 is like a "filter" on where you get long vs short form explanations. That is, --explain E123 would display errors as short unless their code is E123, and then it would give the full details; then --explain all might show everything long.)

In any case, I'm ok with -Zexplain for now also, but it's something we should decide eventually.

@nikomatsakis
Copy link
Contributor

Do we have a tracking issue for this feature? If so, we ought to start documenting these questions.

the additional information the fat pointer holds is their size.");
err.note("to fix this error, don't try to cast directly between thin and fat \
pointers");
err.help("for more information about casts, take a look at
Copy link
Member

@zackmdavis zackmdavis Jan 22, 2018

Choose a reason for hiding this comment

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

missing backslash? (notice enormous margin before "The Book" in the screenshot)

@zackmdavis
Copy link
Member

Using a template is a good possibility, but I feel it can be approached independently from the introduction of the flag.

We should keep in mind that deferring work to the future is only a good idea when the minimal PR leaves the code base in a better state than it was previously (even if it's not optimal); we don't want giant explanations cluttering up our code forever if no one gets around to implementing templates in a timely manner.

@estebank estebank force-pushed the explain branch 4 times, most recently from 4988c46 to 3f3198c Compare January 22, 2018 22:53
@estebank
Copy link
Contributor Author

estebank commented Jan 23, 2018

9b4960e is an early mockup of what StructuredDiagnostics would look like. Right now I'm not too happy with how it looks, as it is slightly more verbose than the previous code, but I think it works as a starting point for talking and iterating upon. Having all the diagnostic errors that could use templates in one place would make it easier to migrate them once such a solution is written.

@estebank estebank force-pushed the explain branch 2 times, most recently from 16f7f68 to 9b4960e Compare January 23, 2018 02:35
@nikomatsakis
Copy link
Contributor

The more I think about it, the more I like --teach. I think we should call this -Zteach for now =)

}
err.emit();
use structured_errors::{SizedUnsizedCastError, StructuredDiagnostic};
SizedUnsizedCastError::new(&fcx.tcx.sess,
Copy link
Contributor

Choose a reason for hiding this comment

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

Personally, I'd rather something with labels I think, like:

SizedUnsizedCastError {
    span: self.span,
    thin_ty: self.expr_ty,
    fat_ty: fcx.ty_to_string(self.cast_ty) // although if we could do `self.cast_ty` it'd be even better
}.emit(fcx.tcx);

These labels would then also appear in the templating logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm thinking that the templating could look something like the following:

diagnostic_template!(
Any independent text will be notes.

Such as this one and the previous one.

Here is where a span would appear:
$secondary_span the label for the span immediately after

I haven't thought about how to deal with suggestions.
)
error[E0XXX]: error message outside of template
  --> $FILE:21:9
   |
21 |         foo();
   |         ^^^^^
   = note: Any independent text will be notes.

          Such as this one and the previous one.
note: Here is where a span would appear:
  --> $FILE:21:9
   |
21 |         foo();
   |         ^^^^^ the label for the span immediately after
   = note: I haven't thought about how to deal with suggestions.

In the background it would convert the template string into calls to err.*().

How does that sound?

Copy link
Contributor

@nikomatsakis nikomatsakis Jan 24, 2018

Choose a reason for hiding this comment

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

Interesting. Quite different than what I had in mind, but I like it as a start, and maybe more practical than some of my more grandiose ideas =)

I think one key question is whether the --teach output would still have the "basic structure" of the messages that we've been giving (as in this PR), or whether it would change to something more essay like.

I think I had initially imagined that, in --teach mode, we would change "our look" somewhat drastically. e.g (using E0010 as an example):

error[E0010]: boxed values cannot be used in statics
  --> $FILE:21:9
  |
21 |         const CON : Box<i32> = box 0;
   |                                ^^^

The value of statics and constants must be known at compile time, and they live
for the entire lifetime of a program. Creating a boxed value allocates memory on
the heap at runtime, and therefore cannot be done at compile time.

For more complex examples, there might be multiple snippets:

error[E0010]: shadowed constant `CON`
  --> $FILE:21:9
  |
21 |         const CON : Box<i32> = box 0;
   |               ^^^

This code is illegal. The problem is that the const CON 
is shadowed by another constant declared earlier, also named `CON`:

  --> $FILE:18:9
  |
18 |         const CON : Box<i32> = box 22;
   |               ^^^

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The only reason I wasn't considering moving in that direction is because I though we wouldn't want to present the same explanation over and over again, so mixing the current diagnostics with the teach diagnostics would be a bit jarring. But if we don't mind either mixing both styles or repeating walls of text, then I don't see why we wouldn't do it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, I think that the differences in output could act like a stylesheet, where the DiagnosticBuilder is still created in the same way, but when emitting it to the output we change how things are presented depending on wether we're in teach mode or not, by removing the left margin on notes, line wrapping, how we deal with suggestions, maybe even highlighting code based on this.

Create the concept of an `StructuredDiagnostic` that is self-contained
with enough knowledge of all variables to create a `DiagnosticBuilder`,
including different possible versions (one line output and expanded
explanations).
@estebank estebank changed the title Add -Z explain flag to provide extended diagnostic help Add -Z teach flag to provide extended diagnostic help Jan 23, 2018
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

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

OK, good start. I just left a nit that I think a comment would be good (not that this is a particularly confusing case, just that I think we should start to comment more)

r=me with that

@@ -244,6 +244,7 @@ pub struct Handler {
continue_after_error: Cell<bool>,
delayed_span_bug: RefCell<Option<Diagnostic>>,
tracked_diagnostics: RefCell<Option<Vec<Diagnostic>>>,
tracked_diagnostic_codes: RefCell<FxHashSet<DiagnosticId>>,
Copy link
Contributor

Choose a reason for hiding this comment

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

can we put a comment on this field explaining what it's for?

@@ -575,13 +577,21 @@ impl Handler {
(ret, diagnostics)
}

pub fn code_emitted(&self, code: &DiagnosticId) -> bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

comment (short one would suffice)

e.g., /// True if a diagnostic with this code has already been emitted. Used to suppress duplicate messages with -Zteach.

@nikomatsakis
Copy link
Contributor

I think however we should think about some kind of public document laying out the desired design here at some point. We could probably get a bunch of people involved in making this happen if we do it right!

@nikomatsakis nikomatsakis 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 Jan 25, 2018
@estebank
Copy link
Contributor Author

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Jan 25, 2018

📌 Commit 2b73733 has been approved by nikomatsakis

@estebank estebank 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 Jan 25, 2018
@bors bors merged commit 2b73733 into rust-lang:master Jan 26, 2018
bors added a commit that referenced this pull request Feb 12, 2018
Add `-Zteach` documentation

Add extra inline documentation to E0019, E0016, E0013, E0396, E0017,
E0018, E0010, E0022, E0030, E0029, E0033, E0026 and E0027.

Follow up to #47652.
@estebank estebank deleted the explain branch November 9, 2023 05:25
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants