Stabilize short error format

[GuillaumeGomez]

r? @oli-obk

Added in #44636

[oli-obk]

Does this have a tracking issue?

[GuillaumeGomez]

No, it's just a format I added a long time ago. I think it's time to stabilize it now.

[oli-obk]

@rfcbot fcp merge

This is a simple addition that is very useful for simple IDEs without rls support or just getting a good overview of all errors without the "noise" of details. I don't know of any open questions about it, except that some errors display very badly (e.g. mismatched types doesn't show the types). This is true for rls rendering, too, and we don't give guarantees on diagnostic output stability, so we can fix it in the future.

An output example can be found in https://github.com/GuillaumeGomez/rust/blob/3ac4f6d7a41caebdf612c079d0bf13b0f54bee74/src/test/ui/short-error-format.stderr

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Zoxc
• @cramertj
• @eddyb
• @estebank
• @michaelwoerister
• @nagisa
• @nikomatsakis
• @nrc
• @oli-obk
• @petrochenkov
• @pnkfelix

Concerns:

• details resolved by Stabilize short error format #49546 (comment)
• gnu-compatible resolved by Stabilize short error format #49546 (comment)
• weight resolved by Stabilize short error format #49546 (comment)
• what-is-being-stabilized resolved by Stabilize short error format #49546 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nrc]

@rfcbot concern weight

Is this pulling its weight? Are people and/or tools using it? Do we have reports that it is satisfying their needs properly and is not just a stop gap for them?

[nrc]

@rfcbot concern details

Many errors don't make sense without the details (the secondary diagnostics), or at least are not very clear. Is this a problem here? Would the short form be better if it included these, but excluded the code snippets and some other stuff?

(Having registered both these concerns, my inclination is still to stabilise, however, I do want to check we're doing the right thing).

Also cc @rust-lang/dev-tools

[GuillaumeGomez]

Is this pulling its weight? Are people and/or tools using it? Do we have reports that it is satisfying their needs properly and is not just a stop gap for them?

I know a few who are using it yes (the ones who asked for it). They use it to avoid getting huge rustc output mainly, not for tooling.

[petrochenkov]

I tried it today and yesterday and I like it, in general.
Some errors are not adapted for this diagnostic style though and give completely useless messages like "type mismatch" without any details, but they may be improved.

[nikomatsakis]

I have no idea what is being "stabilized" here. Surely not the text of the messages. Something about the format? If so, what? It'd be nice to see some documentation to that effect.

[nikomatsakis]

(Personally, I feel this could have merited an RFC, also.)

[estebank]

Do we have reports that it is satisfying their needs properly and is not just a stop gap for them?

There's a vocal small group of people that really like this feature. The increase in complexity is fairly contained.

Some errors are not adapted for this diagnostic style though and give completely useless messages like "type mismatch" without any details, but they may be improved.

I'm yet to write down a proposal pointing out (been offline for two weeks), but I want to formalize the way all errors are written to make short errors always make sense. Labels and notes should provide extra context and guidance, not be mandatory for understanding, although for the type mismatch errors we might want to wait until we have a way to use "shorter" (local namespace) type names to avoid overly long messages.

As to @nikomatsakis' comments, I feel that the improvement of the text to fit this format can be tackled progressively over time and the feature is small and obscure enough (I foresee few people to use it on a regular basis, and the ones that do are more likely to accept the growing pains until we improve the messages) to not be a problem to stabilize it as presented.

[Manishearth]

Perhaps we can add a ~/.cargo/config key for this? You can already do this as a rustflags key but a dedicated key should be nice.

IMO folks should not be interacting with Rust flags directly as much as possible.

[pietroalbini]

Ping from triage @rust-lang/compiler! How's the discussion going for this?

[nikomatsakis]

@estebank

As to @nikomatsakis' comments, I feel that the improvement of the text to fit this format can be tackled progressively over time and the feature is small and obscure enough (I foresee few people to use it on a regular basis, and the ones that do are more likely to accept the growing pains until we improve the messages) to not be a problem to stabilize it as presented.

I still do not know what we are stabilizing! Can somebody please write that up? All I see:

r? @oli-obk
Added in #44636

I would like to see something like the report in this issue:

#48854 (comment)

It doesn't have to be long, just say what is being stabilized and not. =)

[nikomatsakis]

Also, how it is tested =)

[nikomatsakis]

Some more discussion on IRC here. Specifically, I would like to know:

• We are stabilizing some kind of flag that selects this output. What is that flag? Is there an environment variable? How does it work?
• Are we stabilizing anything about the output? The fact that it is one line per error? A regex that will match to extract filename/line number? Nothing at all?

Presumably we are not stabilizing the specific text of error messages, which I guess we would never do.

Is there documentation, or a plan to document? Are there tests?

[nikomatsakis]

@rfcbot concern what-is-being-stabilized

As noted here, I don't really know what we are discussing yet and would like to see some documentation of it =)

[QuietMisdreavus]

Here's what i know about this feature. @GuillaumeGomez can fill in more specifics if i'm missing something.

• This adds a new option to the --error-format flag: short.
• Passing --error-format short to rustc is like --error-format human, but it will omit everything but the "first line" of an error. Help messages, span displays, supplementary info, things like that. When rustc emits an error under this format, it only prints the file, line, column, and the initial error message.
• Right now, before this PR, if you wanted to pass --error-format short, you also needed to pass -Z unstable-options. The flag was made unstable since it was a new implementation, in case we wanted to change how it was named or something significant about its implementation or something like that. The unstable requirement was added in Add short error message-format #44636. This PR removes that.
• When the flag was initially implemented, i opened a PR to Cargo to add this option to their --message-format flag to match, but it was closed since the option was so new and needed to be marked unstable. Presumably, if this PR is merged and the unstable requirement is lifted, that PR can be reopened.

If there are other implications to adding an error format, i haven't considered them. I personally think it's harmless to add, but i also didn't write it. 😁

EDIT: For an example of how this looks, there's a UI test that shows it off.

[nikomatsakis]

So I would specifically like to know if we are committing to:

file.rs:LL:CC - error[E0308]: XXX

I think we should consider adopting one of the standard gnu formats, which I think we almost do, except that we should say file:LL:CC:.

[nikomatsakis]

@rfcbot resolved what-is-being-stabilized

thanks @QuietMisdreavus !

[nikomatsakis]

@rfcbot concern gnu-compatible

I think the output should be compatible with the standard gnu formats, which I think we almost do, except that we should say file:LL:CC: (i.e., colon after the column number). Not sure what happens for more complex line/column information.

[nikomatsakis]

@rfcbot resolve what-is-being-stabilized

[oli-obk]

@bors r+

[bors]

📌 Commit 0be4cb9 has been approved by oli-obk

[bors]

🔒 Merge conflict

[GuillaumeGomez]

Didn't have merge conflict apparently but rebased just in case...

[GuillaumeGomez]

@bors: r=oli-obk

[bors]

📌 Commit 426b63f has been approved by oli-obk

[bors]

⌛ Testing commit 426b63f with merge 1ffb321...

[bors]

💥 Test timed out

[nagisa]

This is a 2nd time i see bors reporting a timeout error incorrectly.

…

On Fri, Jun 1, 2018, 05:59 bors ***@***.***> wrote: 💥 Test timed out — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49546 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0ih9d--J6EfUUBcgjh6nM5z5gmU0ks5t4K33gaJpZM4TCoV5> .

[Manishearth]

Iirc this happens when a previous stuck build eventually times out (on the bors side -- usually it's died ages ago on Travis but bors doesn't notice and keeps it around) On Thu, May 31, 2018, 9:45 PM Simonas Kazlauskas <notifications@github.com> wrote:

…

This is a 2nd time i see bors reporting a timeout error incorrectly. On Fri, Jun 1, 2018, 05:59 bors ***@***.***> wrote: > 💥 Test timed out > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#49546 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AApc0ih9d--J6EfUUBcgjh6nM5z5gmU0ks5t4K33gaJpZM4TCoV5 > > . > — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#49546 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABivSInOHmQ1DDeHHDnNDyEUHAPYiK0Iks5t4MbqgaJpZM4TCoV5> .