tree-wide: fix rustdoc warnings, add some links

crates/hir/src/semantics/source_to_def.rs

@@ -51,7 +51,7 @@
 //! The `GetDeclaredType` takes `Syntax` as input, and returns `Symbol` as
 //! output. First, it retrieves a `Symbol` for parent `Syntax`:
 //!
-//! * https://sourceroslyn.io/#Microsoft.CodeAnalysis.CSharp/Compilation/SyntaxTreeSemanticModel.cs,1423
+//! * <https://sourceroslyn.io/#Microsoft.CodeAnalysis.CSharp/Compilation/SyntaxTreeSemanticModel.cs,1423>
 //!
 //! Then, it iterates parent symbol's children, looking for one which has the
 //! same text span as the original node:

crates/hir_ty/src/diagnostics/match_check/deconstruct_pat.rs

@@ -39,8 +39,7 @@
 //!
 //! Splitting is implemented in the [`Constructor::split`] function. We don't do splitting for
 //! or-patterns; instead we just try the alternatives one-by-one. For details on splitting
-//! wildcards, see [`SplitWildcard`]; for integer ranges, see [`SplitIntRange`]; for slices, see
-//! [`SplitVarLenSlice`].
+//! wildcards, see [`SplitWildcard`]; for integer ranges, see [`SplitIntRange`].
 
 use std::{
     cmp::{max, min},

crates/ide_db/src/helpers.rs

@@ -120,8 +120,8 @@ pub fn visit_file_defs(
 ///
 /// Note that, by default, rust-analyzer tests **do not** include core or std
 /// libraries. If you are writing tests for functionality using [`FamousDefs`],
-/// you'd want to include [minicore](test_utils::MiniCore) declaration at the
-/// start of your tests:
+/// you'd want to include minicore (see `test_utils::MiniCore`) declaration at
+/// the start of your tests:
 ///
 /// ```
 /// //- minicore: iterator, ord, derive

crates/parser/src/grammar.rs

@@ -6,9 +6,9 @@
 //! each submodule starts with `use super::*` import and exports
 //! "public" productions via `pub(super)`.
 //!
-//! See docs for `Parser` to learn about API, available to the grammar,
-//! and see docs for `Event` to learn how this actually manages to
-//! produce parse trees.
+//! See docs for [`Parser`](super::parser::Parser) to learn about API,
+//! available to the grammar, and see docs for [`Event`](super::event::Event)
+//! to learn how this actually manages to produce parse trees.
 //!
 //! Code in this module also contains inline tests, which start with
 //! `// test name-of-the-test` comment and look like this:

crates/parser/src/lib.rs

@@ -1,17 +1,20 @@
 //! The Rust parser.
 //!
 //! The parser doesn't know about concrete representation of tokens and syntax
-//! trees. Abstract `TokenSource` and `TreeSink` traits are used instead. As a
-//! consequence, this crates does not contain a lexer.
+//! trees. Abstract [`TokenSource`] and [`TreeSink`] traits are used instead.
+//! As a consequence, this crate does not contain a lexer.
 //!
-//! The `Parser` struct from the `parser` module is a cursor into the sequence
-//! of tokens. Parsing routines use `Parser` to inspect current state and
-//! advance the parsing.
+//! The [`Parser`] struct from the [`parser`] module is a cursor into the
+//! sequence of tokens.  Parsing routines use [`Parser`] to inspect current
+//! state and advance the parsing.
 //!
-//! The actual parsing happens in the `grammar` module.
+//! The actual parsing happens in the [`grammar`] module.
 //!
-//! Tests for this crate live in `syntax` crate.
+//! Tests for this crate live in the `syntax` crate.
+//!
+//! [`Parser`]: crate::parser::Parser
 
+#![allow(rustdoc::private_intra_doc_links)]
 #[macro_use]
 mod token_set;
 #[macro_use]

crates/parser/src/parser.rs

@@ -14,7 +14,7 @@
 /// `Parser` struct provides the low-level API for
 /// navigating through the stream of tokens and
 /// constructing the parse tree. The actual parsing
-/// happens in the `grammar` module.
+/// happens in the [`grammar`](super::grammar) module.
 ///
 /// However, the result of this `Parser` is not a real
 /// tree, but rather a flat stream of events of the form
@@ -262,7 +262,7 @@ fn push_event(&mut self, event: Event) {
     }
 }
 
-/// See `Parser::start`.
+/// See [`Parser::start`].
 pub(crate) struct Marker {
     pos: u32,
     bomb: DropBomb,
@@ -320,7 +320,8 @@ fn new(start_pos: u32, finish_pos: u32, kind: SyntaxKind) -> Self {
     /// node `A`, then complete it, and then after parsing the
     /// whole `A`, decide that it should have started some node
     /// `B` before starting `A`. `precede` allows to do exactly
-    /// that. See also docs about `forward_parent` in `Event::Start`.
+    /// that. See also docs about
+    /// [`Event::Start::forward_parent`](crate::event::Event::Start::forward_parent).
     ///
     /// Given completed events `[START, FINISH]` and its corresponding
     /// `CompletedMarker(pos: 0, _)`.

crates/syntax/src/ast/node_ext.rs

@@ -197,12 +197,12 @@ pub enum AttrKind {
 }
 
 impl AttrKind {
-    /// Returns `true` if the attr_kind is [`Inner`].
+    /// Returns `true` if the attr_kind is [`Inner`](Self::Inner).
     pub fn is_inner(&self) -> bool {
         matches!(self, Self::Inner)
     }
 
-    /// Returns `true` if the attr_kind is [`Outer`].
+    /// Returns `true` if the attr_kind is [`Outer`](Self::Outer).
     pub fn is_outer(&self) -> bool {
         matches!(self, Self::Outer)
     }