Skip to content

Commit 9230311

Browse files
authored
Rollup merge of rust-lang#57882 - euclio:unused-doc-attributes, r=estebank
overhaul unused doc comments lint This PR contains a number of improvements to the `unused_doc_comments` lint. - Extends the span to cover the entire comment when using sugared doc comments. - Triggers the lint for all unused doc comments on a node, instead of just the first one. - Triggers the lint on macro expansions, and provides a help note explaining that doc comments must be expanded by the macro. - Adds a label pointing at the node that cannot be documented. Furthermore, this PR fixes any instances in rustc where a macro expansion was erroneously documented.
2 parents 89f0a22 + 871e460 commit 9230311

File tree

15 files changed

+349
-166
lines changed

15 files changed

+349
-166
lines changed

src/libcore/num/mod.rs

+1-1
Original file line numberDiff line numberDiff line change
@@ -4646,7 +4646,7 @@ macro_rules! rev {
46464646
)*}
46474647
}
46484648

4649-
/// intra-sign conversions
4649+
// intra-sign conversions
46504650
try_from_upper_bounded!(u16, u8);
46514651
try_from_upper_bounded!(u32, u16, u8);
46524652
try_from_upper_bounded!(u64, u32, u16, u8);

src/librustc/hir/mod.rs

+8-8
Original file line numberDiff line numberDiff line change
@@ -115,15 +115,15 @@ impl serialize::UseSpecializedDecodable for HirId {
115115
// hack to ensure that we don't try to access the private parts of `ItemLocalId` in this module
116116
mod item_local_id_inner {
117117
use rustc_data_structures::indexed_vec::Idx;
118-
/// An `ItemLocalId` uniquely identifies something within a given "item-like",
119-
/// that is within a hir::Item, hir::TraitItem, or hir::ImplItem. There is no
120-
/// guarantee that the numerical value of a given `ItemLocalId` corresponds to
121-
/// the node's position within the owning item in any way, but there is a
122-
/// guarantee that the `LocalItemId`s within an owner occupy a dense range of
123-
/// integers starting at zero, so a mapping that maps all or most nodes within
124-
/// an "item-like" to something else can be implement by a `Vec` instead of a
125-
/// tree or hash map.
126118
newtype_index! {
119+
/// An `ItemLocalId` uniquely identifies something within a given "item-like",
120+
/// that is within a hir::Item, hir::TraitItem, or hir::ImplItem. There is no
121+
/// guarantee that the numerical value of a given `ItemLocalId` corresponds to
122+
/// the node's position within the owning item in any way, but there is a
123+
/// guarantee that the `LocalItemId`s within an owner occupy a dense range of
124+
/// integers starting at zero, so a mapping that maps all or most nodes within
125+
/// an "item-like" to something else can be implement by a `Vec` instead of a
126+
/// tree or hash map.
127127
pub struct ItemLocalId { .. }
128128
}
129129
}

src/librustc/middle/region.rs

+17-18
Original file line numberDiff line numberDiff line change
@@ -132,25 +132,24 @@ pub enum ScopeData {
132132
Remainder(FirstStatementIndex)
133133
}
134134

135-
/// Represents a subscope of `block` for a binding that is introduced
136-
/// by `block.stmts[first_statement_index]`. Such subscopes represent
137-
/// a suffix of the block. Note that each subscope does not include
138-
/// the initializer expression, if any, for the statement indexed by
139-
/// `first_statement_index`.
140-
///
141-
/// For example, given `{ let (a, b) = EXPR_1; let c = EXPR_2; ... }`:
142-
///
143-
/// * the subscope with `first_statement_index == 0` is scope of both
144-
/// `a` and `b`; it does not include EXPR_1, but does include
145-
/// everything after that first `let`. (If you want a scope that
146-
/// includes EXPR_1 as well, then do not use `Scope::Remainder`,
147-
/// but instead another `Scope` that encompasses the whole block,
148-
/// e.g., `Scope::Node`.
149-
///
150-
/// * the subscope with `first_statement_index == 1` is scope of `c`,
151-
/// and thus does not include EXPR_2, but covers the `...`.
152-
153135
newtype_index! {
136+
/// Represents a subscope of `block` for a binding that is introduced
137+
/// by `block.stmts[first_statement_index]`. Such subscopes represent
138+
/// a suffix of the block. Note that each subscope does not include
139+
/// the initializer expression, if any, for the statement indexed by
140+
/// `first_statement_index`.
141+
///
142+
/// For example, given `{ let (a, b) = EXPR_1; let c = EXPR_2; ... }`:
143+
///
144+
/// * the subscope with `first_statement_index == 0` is scope of both
145+
/// `a` and `b`; it does not include EXPR_1, but does include
146+
/// everything after that first `let`. (If you want a scope that
147+
/// includes EXPR_1 as well, then do not use `Scope::Remainder`,
148+
/// but instead another `Scope` that encompasses the whole block,
149+
/// e.g., `Scope::Node`.
150+
///
151+
/// * the subscope with `first_statement_index == 1` is scope of `c`,
152+
/// and thus does not include EXPR_2, but covers the `...`.
154153
pub struct FirstStatementIndex { .. }
155154
}
156155

src/librustc/ty/context.rs

+13-6
Original file line numberDiff line numberDiff line change
@@ -1873,9 +1873,11 @@ pub mod tls {
18731873
rayon_core::tlv::get()
18741874
}
18751875

1876-
/// A thread local variable which stores a pointer to the current ImplicitCtxt
18771876
#[cfg(not(parallel_queries))]
1878-
thread_local!(static TLV: Cell<usize> = Cell::new(0));
1877+
thread_local! {
1878+
/// A thread local variable which stores a pointer to the current ImplicitCtxt.
1879+
static TLV: Cell<usize> = Cell::new(0);
1880+
}
18791881

18801882
/// Sets TLV to `value` during the call to `f`.
18811883
/// It is restored to its previous value after.
@@ -1992,10 +1994,15 @@ pub mod tls {
19921994
})
19931995
}
19941996

1995-
/// Stores a pointer to the GlobalCtxt if one is available.
1996-
/// This is used to access the GlobalCtxt in the deadlock handler
1997-
/// given to Rayon.
1998-
scoped_thread_local!(pub static GCX_PTR: Lock<usize>);
1997+
scoped_thread_local! {
1998+
// FIXME: This should be a doc comment, but the macro does not allow attributes:
1999+
// https://github.com/alexcrichton/scoped-tls/pull/8
2000+
//
2001+
// Stores a pointer to the GlobalCtxt if one is available.
2002+
// This is used to access the GlobalCtxt in the deadlock handler
2003+
// given to Rayon.
2004+
pub static GCX_PTR: Lock<usize>
2005+
}
19992006

20002007
/// Creates a TyCtxt and ImplicitCtxt based on the GCX_PTR thread local.
20012008
/// This is used in the deadlock handler.

src/librustc/ty/mod.rs

+35-35
Original file line numberDiff line numberDiff line change
@@ -1489,42 +1489,42 @@ impl<'tcx> InstantiatedPredicates<'tcx> {
14891489
}
14901490
}
14911491

1492-
/// "Universes" are used during type- and trait-checking in the
1493-
/// presence of `for<..>` binders to control what sets of names are
1494-
/// visible. Universes are arranged into a tree: the root universe
1495-
/// contains names that are always visible. Each child then adds a new
1496-
/// set of names that are visible, in addition to those of its parent.
1497-
/// We say that the child universe "extends" the parent universe with
1498-
/// new names.
1499-
///
1500-
/// To make this more concrete, consider this program:
1501-
///
1502-
/// ```
1503-
/// struct Foo { }
1504-
/// fn bar<T>(x: T) {
1505-
/// let y: for<'a> fn(&'a u8, Foo) = ...;
1506-
/// }
1507-
/// ```
1508-
///
1509-
/// The struct name `Foo` is in the root universe U0. But the type
1510-
/// parameter `T`, introduced on `bar`, is in an extended universe U1
1511-
/// -- i.e., within `bar`, we can name both `T` and `Foo`, but outside
1512-
/// of `bar`, we cannot name `T`. Then, within the type of `y`, the
1513-
/// region `'a` is in a universe U2 that extends U1, because we can
1514-
/// name it inside the fn type but not outside.
1515-
///
1516-
/// Universes are used to do type- and trait-checking around these
1517-
/// "forall" binders (also called **universal quantification**). The
1518-
/// idea is that when, in the body of `bar`, we refer to `T` as a
1519-
/// type, we aren't referring to any type in particular, but rather a
1520-
/// kind of "fresh" type that is distinct from all other types we have
1521-
/// actually declared. This is called a **placeholder** type, and we
1522-
/// use universes to talk about this. In other words, a type name in
1523-
/// universe 0 always corresponds to some "ground" type that the user
1524-
/// declared, but a type name in a non-zero universe is a placeholder
1525-
/// type -- an idealized representative of "types in general" that we
1526-
/// use for checking generic functions.
15271492
newtype_index! {
1493+
/// "Universes" are used during type- and trait-checking in the
1494+
/// presence of `for<..>` binders to control what sets of names are
1495+
/// visible. Universes are arranged into a tree: the root universe
1496+
/// contains names that are always visible. Each child then adds a new
1497+
/// set of names that are visible, in addition to those of its parent.
1498+
/// We say that the child universe "extends" the parent universe with
1499+
/// new names.
1500+
///
1501+
/// To make this more concrete, consider this program:
1502+
///
1503+
/// ```
1504+
/// struct Foo { }
1505+
/// fn bar<T>(x: T) {
1506+
/// let y: for<'a> fn(&'a u8, Foo) = ...;
1507+
/// }
1508+
/// ```
1509+
///
1510+
/// The struct name `Foo` is in the root universe U0. But the type
1511+
/// parameter `T`, introduced on `bar`, is in an extended universe U1
1512+
/// -- i.e., within `bar`, we can name both `T` and `Foo`, but outside
1513+
/// of `bar`, we cannot name `T`. Then, within the type of `y`, the
1514+
/// region `'a` is in a universe U2 that extends U1, because we can
1515+
/// name it inside the fn type but not outside.
1516+
///
1517+
/// Universes are used to do type- and trait-checking around these
1518+
/// "forall" binders (also called **universal quantification**). The
1519+
/// idea is that when, in the body of `bar`, we refer to `T` as a
1520+
/// type, we aren't referring to any type in particular, but rather a
1521+
/// kind of "fresh" type that is distinct from all other types we have
1522+
/// actually declared. This is called a **placeholder** type, and we
1523+
/// use universes to talk about this. In other words, a type name in
1524+
/// universe 0 always corresponds to some "ground" type that the user
1525+
/// declared, but a type name in a non-zero universe is a placeholder
1526+
/// type -- an idealized representative of "types in general" that we
1527+
/// use for checking generic functions.
15281528
pub struct UniverseIndex {
15291529
DEBUG_FORMAT = "U{}",
15301530
}

src/librustc/ty/sty.rs

+39-39
Original file line numberDiff line numberDiff line change
@@ -1060,46 +1060,46 @@ impl<'a, 'gcx, 'tcx> ParamTy {
10601060
}
10611061
}
10621062

1063-
/// A [De Bruijn index][dbi] is a standard means of representing
1064-
/// regions (and perhaps later types) in a higher-ranked setting. In
1065-
/// particular, imagine a type like this:
1066-
///
1067-
/// for<'a> fn(for<'b> fn(&'b isize, &'a isize), &'a char)
1068-
/// ^ ^ | | |
1069-
/// | | | | |
1070-
/// | +------------+ 0 | |
1071-
/// | | |
1072-
/// +--------------------------------+ 1 |
1073-
/// | |
1074-
/// +------------------------------------------+ 0
1075-
///
1076-
/// In this type, there are two binders (the outer fn and the inner
1077-
/// fn). We need to be able to determine, for any given region, which
1078-
/// fn type it is bound by, the inner or the outer one. There are
1079-
/// various ways you can do this, but a De Bruijn index is one of the
1080-
/// more convenient and has some nice properties. The basic idea is to
1081-
/// count the number of binders, inside out. Some examples should help
1082-
/// clarify what I mean.
1083-
///
1084-
/// Let's start with the reference type `&'b isize` that is the first
1085-
/// argument to the inner function. This region `'b` is assigned a De
1086-
/// Bruijn index of 0, meaning "the innermost binder" (in this case, a
1087-
/// fn). The region `'a` that appears in the second argument type (`&'a
1088-
/// isize`) would then be assigned a De Bruijn index of 1, meaning "the
1089-
/// second-innermost binder". (These indices are written on the arrays
1090-
/// in the diagram).
1091-
///
1092-
/// What is interesting is that De Bruijn index attached to a particular
1093-
/// variable will vary depending on where it appears. For example,
1094-
/// the final type `&'a char` also refers to the region `'a` declared on
1095-
/// the outermost fn. But this time, this reference is not nested within
1096-
/// any other binders (i.e., it is not an argument to the inner fn, but
1097-
/// rather the outer one). Therefore, in this case, it is assigned a
1098-
/// De Bruijn index of 0, because the innermost binder in that location
1099-
/// is the outer fn.
1100-
///
1101-
/// [dbi]: http://en.wikipedia.org/wiki/De_Bruijn_index
11021063
newtype_index! {
1064+
/// A [De Bruijn index][dbi] is a standard means of representing
1065+
/// regions (and perhaps later types) in a higher-ranked setting. In
1066+
/// particular, imagine a type like this:
1067+
///
1068+
/// for<'a> fn(for<'b> fn(&'b isize, &'a isize), &'a char)
1069+
/// ^ ^ | | |
1070+
/// | | | | |
1071+
/// | +------------+ 0 | |
1072+
/// | | |
1073+
/// +--------------------------------+ 1 |
1074+
/// | |
1075+
/// +------------------------------------------+ 0
1076+
///
1077+
/// In this type, there are two binders (the outer fn and the inner
1078+
/// fn). We need to be able to determine, for any given region, which
1079+
/// fn type it is bound by, the inner or the outer one. There are
1080+
/// various ways you can do this, but a De Bruijn index is one of the
1081+
/// more convenient and has some nice properties. The basic idea is to
1082+
/// count the number of binders, inside out. Some examples should help
1083+
/// clarify what I mean.
1084+
///
1085+
/// Let's start with the reference type `&'b isize` that is the first
1086+
/// argument to the inner function. This region `'b` is assigned a De
1087+
/// Bruijn index of 0, meaning "the innermost binder" (in this case, a
1088+
/// fn). The region `'a` that appears in the second argument type (`&'a
1089+
/// isize`) would then be assigned a De Bruijn index of 1, meaning "the
1090+
/// second-innermost binder". (These indices are written on the arrays
1091+
/// in the diagram).
1092+
///
1093+
/// What is interesting is that De Bruijn index attached to a particular
1094+
/// variable will vary depending on where it appears. For example,
1095+
/// the final type `&'a char` also refers to the region `'a` declared on
1096+
/// the outermost fn. But this time, this reference is not nested within
1097+
/// any other binders (i.e., it is not an argument to the inner fn, but
1098+
/// rather the outer one). Therefore, in this case, it is assigned a
1099+
/// De Bruijn index of 0, because the innermost binder in that location
1100+
/// is the outer fn.
1101+
///
1102+
/// [dbi]: http://en.wikipedia.org/wiki/De_Bruijn_index
11031103
pub struct DebruijnIndex {
11041104
DEBUG_FORMAT = "DebruijnIndex({})",
11051105
const INNERMOST = 0,

0 commit comments

Comments
 (0)