Replace check_attr_crate_level with check_target for #[doc]

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[evavh]

A small change as part of the target checking refactor for #[doc] attribute parsing.

r? @JonathanBrouwer

[rustbot]

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

Suggested change

	&sym::no_crate_inject.to_string(),
	sym::no_crate_inject.as_str()

View changes since the review

[mejrs]

Suggested change

	&s.to_string(),
	s.as_str(),

View changes since the review

[JonathanBrouwer]

Could you make tests for these cases if they don't already exist? I'd expect some stderr changes in this PR

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[evavh]

I tried to add tests for the crate-level attribute checks, but I'm running into an interesting problem: there seems to be no way for the target check to fail. The possible ways for a crate-level attribute to be applied to a non-crate target (that I can think of) are:

1. A #[doc(CRATE_LEVEL_ONLY)] attribute applied to an item: this outputs the error crate-level attribute should be an inner attribute: add an exclamation mark
2. A #![doc(CRATE_LEVEL_ONLY)] attribute applied to an item (ie not at the top of the file): the error is an inner attribute is not permitted in this context

In both cases the compiler throws an error before we even reach the target checking code in doc.rs. The same applies to doc attribute arguments that shouldn't be used crate-level, like fake_variadic. It seems the distinction between inner (#!) and outer (#) attributes is enough to guard against wrong crate/non-crate targets.

The test I wrote covers all doc attribute arguments that check whether they are applied at crate level, and they all throw errors in earlier parsing steps. What do we do with the target checking code that does nothing?

[JonathanBrouwer]

@evavh I took a random crate-level doc attribute, and applied it to a function:

#[doc(html_no_source)]fntest1(){}fntest2(){#![doc(html_no_source)]}

In both cases this produces "this attribute can only be applied at the crate level"
This diagnostic is produced in target checking, so if you hit it you are doing target checking somewhere:

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 215 in ff619e2

pub(crate)fncheck_crate_level(cx:&mutAcceptContext<'_,'sess>,warn:bool){

The diagnostic "an inner attribute is not permitted in this context" is produced when you apply inner attributes to an item that doesn't support inner attributes, such as a struct, and is indeed produced in the parser

structTest{#![doc(html_no_source)]}

@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

These are breaking changes, so they will need a crater run. Alternatively, you could refactor this in a way that doesn't change behavior.

[evavh]

Turns out I was very confused by the "new" diagnostic emitted by check_crate_level called by AttributeParser::check_target. The target checking is still happening correctly with this refactor, though I do think the diagnostic has become worse.

I tried changing the diagnostic in check_crate_level, but that broke all kinds of unrelated tests.

As for breaking changes, using a crate-level doc attribute on the wrong target now emits an ERROR instead of a WARN.

@rustbot ready

[JonathanBrouwer]

If you use AllowListWarnRest instead of AllowList it will warn instead of erroring.
Then to generate the right lint INVALID_DOC_ATTRIBUTES instead of the default UNUSED_ATTRIBUTES we should add a special case here

rust/compiler/rustc_attr_parsing/src/target_checking.rs

Line 173 in ff619e2

}elseif is_diagnostic_attr {

View changes since the review

[JonathanBrouwer]

Is there a reason you removed this from the test?
This is here to show that this doc attribute, incorrectly, is not feature gated

View changes since the review

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web)(plain enhanced)(plain)

Click to see the possible cause of the failure (guessed by this bot)

This error was generated by the lint-docs tool.
This tool extracts documentation for lints from the source code and places
them in the rustc book. See the declare_lint! documentation
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/macro.declare_lint.html
for an example of the format of documentation this tool expects.
To re-run these tests, run: ./x.py test --keep-stage=0 src/tools/lint-docs
The --keep-stage flag should be used if you have already built the compiler
and are only modifying the doc comments to avoid rebuilding the compiler.
Bootstrap failed while executing `--stage 2 test --skip tidy --skip intrinsic-test --skip src/tools/rust-analyzer --skip tests --skip library --skip tidyselftest`
Currently active steps:
test::LintDocs { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } at src/bootstrap/src/core/build_steps/test.rs:4173
doc::RustcBook { build_compiler: Compiler { stage: 1, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, validate: true } at src/bootstrap/src/core/build_steps/test.rs:4186
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/lint-docs --build-rustc-stage 1 --src /checkout/compiler --out /checkout/obj/build/aarch64-unknown-linux-gnu/md-doc/rustc/src/lints --rustc /checkout/obj/build/aarch64-unknown-linux-gnu/stage1/bin/rustc --rustc-target aarch64-unknown-linux-gnu --validate` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1627:23
Executed at: src/bootstrap/src/core/build_steps/doc.rs:1465:13
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:39:24
local time: Tue Sep 1 12:58:18 UTC 2026
network time: Tue, 01 Sep 2026 12:58:18 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"