compiletest: prevent directives from having multiple revisions#156237
Open
lqd wants to merge 2 commits intorust-lang:mainfrom
Open
compiletest: prevent directives from having multiple revisions#156237lqd wants to merge 2 commits intorust-lang:mainfrom
lqd wants to merge 2 commits intorust-lang:mainfrom
Conversation
also update the test to make sure there's an error
Collaborator
|
Some changes occurred in src/tools/compiletest cc @jieyouxu |
rustbot
added
A-compiletest
Collaborator
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Member
|
cc issue #123765 |
Member
Author
|
ah I knew there was an issue about this but couldn't find it with a quick search, thank you @fmease! |
wesleywiser
approved these changes
May 6, 2026
Member
There was a problem hiding this comment.
This seems very reasonable to me but let's see what @jieyouxu thinks.
jieyouxu
approved these changes
May 7, 2026
Member
|
(Eventually I'd like to move these validations to not panic everywhere and produce proper errors but rejecting loudly still much better than silently borked) |
Member
|
@bors r=wesleywiser,jieyouxu rollup |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 7, 2026
…ywiser,jieyouxu compiletest: prevent directives from having multiple revisions Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing. I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc. Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives: ``` multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like //@ [foo]: compile-flags: -Z hello //@ [bar]: compile-flags: -Z hello ```
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 7, 2026
…ywiser,jieyouxu compiletest: prevent directives from having multiple revisions Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing. I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc. Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives: ``` multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like //@ [foo]: compile-flags: -Z hello //@ [bar]: compile-flags: -Z hello ```
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 7, 2026
…ywiser,jieyouxu compiletest: prevent directives from having multiple revisions Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing. I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc. Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives: ``` multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like //@ [foo]: compile-flags: -Z hello //@ [bar]: compile-flags: -Z hello ```
rust-bors Bot
pushed a commit
that referenced
this pull request
May 7, 2026
Rollup of 14 pull requests Successful merges: - #146273 (lint ImproperCTypes: refactor linting architecture (part 2)) - #149509 (Lint unused pub items in binary crates) - #156173 (Fewer global node_id_to_def_id lookups) - #156177 (windows/time: avoid being too close to 0) - #155961 (Deny warnings in the test for crates that are available on stable) - #155981 (Use special DefIds for aliases) - #156109 (Migrate libraries from ptr::slice_from_raw_parts to .cast_slice) - #156130 (Fold/visit tweaks) - #156131 (Metadata macro/query cleanups) - #156202 (llvm: Use correct type for splat mask) - #156227 (Add Trusty OS to the generic error implementation.) - #156237 (compiletest: prevent directives from having multiple revisions) - #156241 (Move tests coercion) - #156258 (Document wasi-sdk minimum versions for WASI targets)
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
May 7, 2026
…ywiser,jieyouxu compiletest: prevent directives from having multiple revisions Right now, a compiletest directive like `//@ [foo,bar] compile-flags: -Z hello` is accepted. While it looks similar to a `//[foo,bar]` error annotation matching multiple revisions, it will instead model a directive for a single revision named `foo,bar` and not for two revisions. Slightly inconsistent/confusing. I don't know that it's common enough to make bigger changes to support it fully (`miri`'s test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses of `line_directive` as possibly creating multiple line directives, one per revision, etc. Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives: ``` multiple revisions aren't supported yet in `//@ [foo,bar] compile-flags: -Z hello`, split them like //@ [foo]: compile-flags: -Z hello //@ [bar]: compile-flags: -Z hello ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Right now, a compiletest directive like
//@ [foo,bar] compile-flags: -Z hellois accepted. While it looks similar to a//[foo,bar]error annotation matching multiple revisions, it will instead model a directive for a single revision namedfoo,barand not for two revisions. Slightly inconsistent/confusing.I don't know that it's common enough to make bigger changes to support it fully (
miri's test harness seems to support that use-case), but since I hit that today, this PR prevents that case for now. Otherwise, I think we'd have to turn all uses ofline_directiveas possibly creating multiple line directives, one per revision, etc.Such a directive will now yield an error, with a best-effort suggestion to split it into multiple single-revision directives: