Allow patternless error and warning matchers

[Jarcho]

fixes #164

This adds support for patternless error matchers (//~ ERRORand//~ WARN`). These come with two restrictions:

• They can't be used on the same line as a matcher with a pattern
• All the patternless matchers in a single test have to be for the same error code.

The reason for the second restriction is the same general reason for having inline annotations in the first place. Since the .stderror file already has the full message the annotation doesn't test anything new, it only helps with reading/writing the test file. If only a single error is being tested, having a message with each annotation is unlikely to add anything but line noise. If there are multiple errors being tested for, then the message helps which error is expected for each annotation.

[Jarcho]

The error message when an unexpected error code is still in need of improvement. I think merging it with the unmatched error message would be easier to read. Also noting which error caused the selection of the expected error code would be good to have.

[RalfJung]

Since the .stderror file already has the full message the annotation doesn't test anything new, it only helps with reading/writing the test file.

I very strongly disagree. The stderr file is easily adjusted by re-blessing. The explicit annotations in the file are absolutely crucial to ensure that this test keeps testing the right thing even as things get re-blessed.

Of course your use of this crate may be different, but IMO relying just on stderr for the output message is way too fragile. I certainly regularly rely on compiletest / ui_test checking that the right message is emitted even in bless mode. I need bless mode because some details change, and it's good to see what changes, but I'd never want to bless changes to the relevant part of the message -- and it's way too easy to miss such changes when re-blessing everything for a large change, so IMO it is crucial to have the key parts of the error message in the rs test file.

Anyway, ui_test can of course have such a mode, but the downsides should be clearly documented (and ideally I could make sure that the Miri test suite never has any patternless matchers).

[oli-obk]

I agree with Ralf, but I also want to support clippy's use case. I think we should change the boolean in

ui_test/src/mode.rs

Line 40 in 3d262a2

require_patterns: bool,

to be an enum, (Require, Optional, RequireWithoutMessage... the names aren't great, but obvious, and can get documented individually).

[Jarcho]

This could also require the code to specified (e.g. //@patternless-error-code:code) which opts into this on each test. It also acts as a guard in case something crazy changes.

Anyway, ui_test can of course have such a mode, but the downsides should be clearly documented (and ideally I could make sure that the Miri test suite never has any patternless matchers).

It looks like Miri doesn't fill in a code on any of it's diagnostics so the current implementation intentionally wouldn't match any of them.

[Alexendoo]

How about in addition to e.g. //~ ERROR: message we accept //~ clippy::some_lint? It's shorter than the original //~ ERROR clippy::some_lint proposal. If dropping the clippy:: prefix is allowed it's not that far away from //~ ERROR in length, aside from those few lints with hefty names

It's clear at the annotation site what is being expected, rather than having to specify/know the file context

It doesn't include the level but I wouldn't expect a test where the level of a single code varies in the same file to exist outside of rustc

[Jarcho]

Implemented @Alexendoo's suggestion. This allows //~ error_code to match either a single warning or error with that error code.

The readme has also been reformatted slightly to mention both forms. The erroneous note about being able to drop the level when giving a pattern has been removed as well. The parser didn't accept that in the first place.

[Jarcho]

Last commit should fix those comments. I'll squash it down if there aren't any issues.

[Jarcho]

Last change adds the ability to specify a global prefix when matching error codes. This is useful for clippy since all of ours start with clippy:: and we don't need to match anything else.

[Jarcho]

Build failures are caused by the upgrade to rust v1.73.