Adjust documentation for compatibility with 2021

This also adjusts the lint docs generation to accept (and ignore) an allow
attribute, rather than expecting the documentation to be immediately followed by
the lint name.
This commit is contained in:
Mark Rousskov 2021-09-20 08:46:26 -04:00
parent f338900826
commit 3b89679671
7 changed files with 35 additions and 28 deletions

View file

@ -13,7 +13,7 @@
///
/// ### Example
///
/// ```rust
/// ```rust,edition2018
/// # #![allow(unused)]
/// [1, 2, 3].into_iter().for_each(|n| { *n; });
/// ```

View file

@ -1686,7 +1686,7 @@ fn check_item(&mut self, cx: &LateContext<'tcx>, item: &'tcx hir::Item<'tcx>) {
///
/// ### Example
///
/// ```rust
/// ```rust,edition2018
/// let x = 123;
/// match x {
/// 0...100 => {}

View file

@ -18,7 +18,7 @@
///
/// ### Example
///
/// ```rust,no_run
/// ```rust,no_run,edition2018
/// panic!("{}");
/// panic!(123);
/// ```

View file

@ -1584,7 +1584,7 @@
///
/// ### Example
///
/// ```rust
/// ```rust,edition2018
/// trait Trait { }
///
/// fn takes_trait_object(_: Box<Trait>) {
@ -3313,7 +3313,7 @@
///
/// ### Example
///
/// ```rust,compile_fail
/// ```rust,edition2018,compile_fail
/// #![deny(rust_2021_prefixes_incompatible_syntax)]
///
/// macro_rules! m {
@ -3333,6 +3333,8 @@
///
/// This lint suggests to add whitespace between the `z` and `"hey"` tokens
/// to keep them separated in Rust 2021.
// Allow this lint -- rustdoc doesn't yet support threading edition into this lint's parser.
#[allow(rustdoc::invalid_rust_codeblocks)]
pub RUST_2021_PREFIXES_INCOMPATIBLE_SYNTAX,
Allow,
"identifiers that will be parsed as a prefix in Rust 2021",

View file

@ -11,10 +11,10 @@
//! should be used when linking each output type requested in this session. This
//! generally follows this set of rules:
//!
//! 1. Each library must appear exactly once in the output.
//! 2. Each rlib contains only one library (it's just an object file)
//! 3. Each dylib can contain more than one library (due to static linking),
//! and can also bring in many dynamic dependencies.
//! 1. Each library must appear exactly once in the output.
//! 2. Each rlib contains only one library (it's just an object file)
//! 3. Each dylib can contain more than one library (due to static linking),
//! and can also bring in many dynamic dependencies.
//!
//! With these constraints in mind, it's generally a very difficult problem to
//! find a solution that's not "all rlibs" or "all dylibs". I have suspicions
@ -22,24 +22,24 @@
//!
//! The current selection algorithm below looks mostly similar to:
//!
//! 1. If static linking is required, then require all upstream dependencies
//! to be available as rlibs. If not, generate an error.
//! 2. If static linking is requested (generating an executable), then
//! attempt to use all upstream dependencies as rlibs. If any are not
//! found, bail out and continue to step 3.
//! 3. Static linking has failed, at least one library must be dynamically
//! linked. Apply a heuristic by greedily maximizing the number of
//! dynamically linked libraries.
//! 4. Each upstream dependency available as a dynamic library is
//! registered. The dependencies all propagate, adding to a map. It is
//! possible for a dylib to add a static library as a dependency, but it
//! is illegal for two dylibs to add the same static library as a
//! dependency. The same dylib can be added twice. Additionally, it is
//! illegal to add a static dependency when it was previously found as a
//! dylib (and vice versa)
//! 5. After all dynamic dependencies have been traversed, re-traverse the
//! remaining dependencies and add them statically (if they haven't been
//! added already).
//! 1. If static linking is required, then require all upstream dependencies
//! to be available as rlibs. If not, generate an error.
//! 2. If static linking is requested (generating an executable), then
//! attempt to use all upstream dependencies as rlibs. If any are not
//! found, bail out and continue to step 3.
//! 3. Static linking has failed, at least one library must be dynamically
//! linked. Apply a heuristic by greedily maximizing the number of
//! dynamically linked libraries.
//! 4. Each upstream dependency available as a dynamic library is
//! registered. The dependencies all propagate, adding to a map. It is
//! possible for a dylib to add a static library as a dependency, but it
//! is illegal for two dylibs to add the same static library as a
//! dependency. The same dylib can be added twice. Additionally, it is
//! illegal to add a static dependency when it was previously found as a
//! dylib (and vice versa)
//! 5. After all dynamic dependencies have been traversed, re-traverse the
//! remaining dependencies and add them statically (if they haven't been
//! added already).
//!
//! While not perfect, this algorithm should help support use-cases such as leaf
//! dependencies being static while the larger tree of inner dependencies are

View file

@ -257,7 +257,8 @@ pub struct ScopeTree {
/// ```
///
/// With the HIR tree (calls numbered for expository purposes)
/// ```
///
/// ```text
/// Call#0(foo, [Call#1(f), Yield(y), Call#2(bar, Call#3(g))])
/// ```
///

View file

@ -149,6 +149,10 @@ fn lints_from_file(&self, path: &Path) -> Result<Vec<Lint>, Box<dyn Error>> {
} else if line.starts_with("// ") {
// Ignore comments.
continue;
} else if line.starts_with("#[allow") {
// Ignore allow of lints (useful for
// invalid_rust_codeblocks).
continue;
} else {
let name = lint_name(line).map_err(|e| {
format!(