mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
abe52cdcc7
rust/tests/rustdoc-ui/lints/lint-group.stderr

55 lines
1.5 KiB
Plaintext
Raw Normal View History

Separate `missing_doc_code_examples` from intra-doc links These two lints have no relation other than both being nightly-only. This allows stabilizing intra-doc links without stabilizing missing_doc_code_examples.
2020-07-27 21:16:41 -05:00
error: missing code example in this documentation
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
--> $DIR/lint-group.rs:19:1
Separate `missing_doc_code_examples` from intra-doc links These two lints have no relation other than both being nightly-only. This allows stabilizing intra-doc links without stabilizing missing_doc_code_examples.
2020-07-27 21:16:41 -05:00
|
LL | /// wait, this doesn't have a doctest?
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: the lint level is defined here
Feature gate the rustdoc::missing_doc_code_examples lint
2022-09-12 13:10:35 -05:00
--> $DIR/lint-group.rs:9:9
Separate `missing_doc_code_examples` from intra-doc links These two lints have no relation other than both being nightly-only. This allows stabilizing intra-doc links without stabilizing missing_doc_code_examples.
2020-07-27 21:16:41 -05:00
|
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
LL | #![deny(rustdoc::missing_doc_code_examples)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Separate `missing_doc_code_examples` from intra-doc links These two lints have no relation other than both being nightly-only. This allows stabilizing intra-doc links without stabilizing missing_doc_code_examples.
2020-07-27 21:16:41 -05:00
Fix some rustdoc error capitalization
2019-11-24 20:42:22 -06:00
error: documentation test in private item
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
--> $DIR/lint-group.rs:22:1
add a lint group for lints emitted by rustdoc
2018-12-10 14:58:57 -06:00
|
LL | / /// wait, this *does* have a doctest?
LL | | ///
LL | | /// ```
LL | | /// println!("sup");
LL | | /// ```
| |_______^
|
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
note: the lint level is defined here
--> $DIR/lint-group.rs:10:9
|
LL | #![deny(rustdoc::all)]
| ^^^^^^^^^^^^
Rename `rustdoc` to `rustdoc::all` When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
2021-03-05 08:50:20 -06:00
= note: `#[deny(rustdoc::private_doc_tests)]` implied by `#[deny(rustdoc::all)]`
add a lint group for lints emitted by rustdoc
2018-12-10 14:58:57 -06:00
Add test for invalid_html_tag lint in deny(rustdoc)
2020-09-26 15:50:34 -05:00
error: missing code example in this documentation
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
--> $DIR/lint-group.rs:29:1
Add test for invalid_html_tag lint in deny(rustdoc)
2020-09-26 15:50:34 -05:00
|
LL | /// <unknown>
| ^^^^^^^^^^^^^
refactor and reword intra-doc link errors This commit refactors intra-doc link error reporting to deduplicate code and decouple error construction from the type of error. This greatly improves flexibility at each error construction site, while reducing the complexity of the diagnostic creation. This commit also rewords the diagnostics for clarity and style: - Diagnostics should not end in periods. - It's unnecessary to say "ignoring it". Since this is a warning by default, it's already clear that the link is ignored.
2020-07-19 12:03:35 -05:00
error: unresolved link to `error`
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
--> $DIR/lint-group.rs:12:29
add a lint group for lints emitted by rustdoc
2018-12-10 14:58:57 -06:00
|
LL | /// what up, let's make an [error]
Improve error messages
2020-10-02 21:53:09 -05:00
| ^^^^^ no item named `error` in scope
add a lint group for lints emitted by rustdoc
2018-12-10 14:58:57 -06:00
|
refactor and reword intra-doc link errors This commit refactors intra-doc link error reporting to deduplicate code and decouple error construction from the type of error. This greatly improves flexibility at each error construction site, while reducing the complexity of the diagnostic creation. This commit also rewords the diagnostics for clarity and style: - Diagnostics should not end in periods. - It's unnecessary to say "ignoring it". Since this is a warning by default, it's already clear that the link is ignored.
2020-07-19 12:03:35 -05:00
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
bless rustdoc-ui
2022-09-23 13:34:34 -05:00
= note: `#[deny(rustdoc::broken_intra_doc_links)]` implied by `#[deny(rustdoc::all)]`
add a lint group for lints emitted by rustdoc
2018-12-10 14:58:57 -06:00
Add test for invalid_html_tag lint in deny(rustdoc)
2020-09-26 15:50:34 -05:00
error: unclosed HTML tag `unknown`
Only include stable lints in `rustdoc::all` group Including unstable lints in the lint group produces unintuitive behavior on stable (see #106289). Meanwhile, if we only included unstable lints on nightly and not on stable, we could end up with confusing bugs that were hard to compare across versions of Rust that lacked code changes. I think that only including stable lints in `rustdoc::all`, no matter the release channel, is the most intuitive option. Users can then control unstable lints individually, which is reasonable since they have to enable the feature gates individually anyway.
2022-12-30 19:09:19 -06:00
--> $DIR/lint-group.rs:29:5
Add test for invalid_html_tag lint in deny(rustdoc)
2020-09-26 15:50:34 -05:00
|
LL | /// <unknown>
| ^^^^^^^^^
|
Rename `rustdoc` to `rustdoc::all` When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like ``` warning: unknown lint: `rustdoc` ``` The lint group still worked when rustdoc ran, since rustdoc added the group itself. This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
2021-03-05 08:50:20 -06:00
= note: `#[deny(rustdoc::invalid_html_tags)]` implied by `#[deny(rustdoc::all)]`
Add test for invalid_html_tag lint in deny(rustdoc)
2020-09-26 15:50:34 -05:00
error: aborting due to 5 previous errors
Make the rustc driver and interface demand driven
2018-12-08 13:30:23 -06:00
Reference in New Issue Copy Permalink