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

allow "NO NOTE" annotations, stop requiring NOTE annotations to be exhaustive #46667

Open
nikomatsakis opened this issue Dec 11, 2017 · 0 comments
Labels
A-compiletest Area: The compiletest test runner A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. E-needs-design This issue needs exploration and design to see how and if we can fix/implement it T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@nikomatsakis
Copy link
Contributor

From #46641:

I've been very much enjoying the fact that UI tests check for ERRORs. I like being able to add minimal annotations to the test that give the kind of "overall parameters" for what the test is testing (that errors occur here, here, and here) and then having the stderr files capture the full behavior.

But there are times when I want to document a subset of the NOTEs that are present. i.e., so that I can outline "other variations in the stderr output may be acceptable, but if this NOTE disappears, that's a big problem". Note that I say subset -- often there are many notes, but it's just one piece I want to guarantee is present.

Before, we required that if you document any note, you must document all notes. The result is that it discourages me from annotating these notes that I want to be present.

(On the other hand, if you can't declare that the set of notes is exhaustive, you can't document that a note should not appear. I don't find this to be something I want to document very often, but it's certainly possible. But we could easily have a "NO_NOTE" annotation or something then.)

What I do for now is to leave comments, but I fear that future people will not read them.

cc @oli-obk @petrochenkov @estebank

@nikomatsakis nikomatsakis added A-testsuite Area: The testsuite used to check the correctness of rustc T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 11, 2017
@XAMPPRocky XAMPPRocky added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Mar 26, 2018
@fmease fmease added the A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself label May 14, 2024
@fmease fmease added the A-compiletest Area: The compiletest test runner label Aug 29, 2024
@jieyouxu jieyouxu added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-needs-design This issue needs exploration and design to see how and if we can fix/implement it and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 17, 2024
@jieyouxu jieyouxu added E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. and removed E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. labels Dec 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. E-needs-design This issue needs exploration and design to see how and if we can fix/implement it T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
Development

No branches or pull requests

4 participants