wrap_comments partially ignores comment_width with bullet lists

[cyphar]

In some fairly specific circumstances, rustfmt with wrap_comments=true will allow comments to wrap a few characters beyond the configured comment_width. So far I have managed to only hit this a few times with bullet points in comments of the following form (these examples were hard-wrapped manually by me and are all within 80 columns -- I would expect rustfmt to do nothing as as result):

// * aaa Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
//   aaq tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
//   aaa veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
//   aaa commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
//   aaa velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
//   aaa occaecat cupidatat non proident, sunt in culpa qui officia deserunt
//   aaa mollit anim id est laborum.

fn bad_comment() {
    // * Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    //   tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
    //   veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
    //   commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
    //   velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
    //   occaecat cupidatat non proident, sunt in culpa qui officia deserunt
    //   mollit anim id est laborum.

    ()
}

fn comment_ignored() {
    foobar();

    // * Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
    //   tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
    //   veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
    //   commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
    //   velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
    //   occaecat cupidatat non proident, sunt in culpa qui officia deserunt
    //   mollit anim id est laborum.
}

If you then try to use rustfmt you will see that it suggests wrappings that exceed 80 characters for a few lines where the continuing word is short. Note that it seems there must be something after the comment for comments in functions -- comment_ignored is accepted by rustfmt despite having identical comment text to bad_comment.

% rustc +nightly --version
rustc 1.95.0-nightly (7057231bd 2026-02-11)
% rustfmt +nightly --version
rustfmt 1.8.0-nightly (7057231bd7 2026-02-11)
% % rustfmt +nightly --config=wrap_comments=true --check test.rs

Diff in /home/cyphar/tmp/foo.rs:2:
 //   aaq tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
 //   aaa veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
 //   aaa commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
-//   aaa velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
-//   aaa occaecat cupidatat non proident, sunt in culpa qui officia deserunt
-//   aaa mollit anim id est laborum.
+//   aaa velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint aaa
+//   occaecat cupidatat non proident, sunt in culpa qui officia deserunt aaa
+//   mollit anim id est laborum.

 fn bad_comment() {
     // * Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
Diff in /home/cyphar/tmp/foo.rs:11:
     //   tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
     //   veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
     //   commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
-    //   velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
-    //   occaecat cupidatat non proident, sunt in culpa qui officia deserunt
-    //   mollit anim id est laborum.
+    //   velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat
+    //   cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id
+    //   est laborum.

     ()
 }
Diff in /home/cyphar/tmp/foo.rs:34:
 //   aaq tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
 //   aaa veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
 //   aaa commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
-//   aaa velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
-//   aaa occaecat cupidatat non proident, sunt in culpa qui officia deserunt
-//   aaa mollit anim id est laborum.
+//   aaa velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint aaa
+//   occaecat cupidatat non proident, sunt in culpa qui officia deserunt aaa
+//   mollit anim id est laborum.

As far as I can see, this occurs on all editions.

[cyphar]

For reference, this is the actual code which most recently triggered this issue:

/// Parse a `/proc/self/fdinfo` file, and fetch the first value that matches
/// `want_field_name`, with some extra verification.
///
/// This function will verify that the `fdinfo` file contains an `ino` field
/// that matches the actual inode number of the passed `fd`. This is intended to
/// make it very difficult for an attacker to create a convincingly fake
/// `fdinfo` file (as a final fallback for `RESOLVE_NO_XDEV` emulation).
pub(crate) fn fd_get_verify_fdinfo<T>(
    rdr: &mut (impl Read + Seek),
    fd: impl AsFd,
    want_field_name: &str,
) -> Result<Option<T>, Error>
where
    T: FromStr,
    T::Err: Into<Error>,
{
    let fd = fd.as_fd();

    // Verify that the "ino" field in fdinfo matches the real inode number of
    // our file descriptor. This makes attacks harder (if not near impossible,
    // outside of very constrained situations):
    //
    // * An attacker would probably struggle to always accurately guess the
    //   inode number of files that the process is trying to operate on. Yes, if
    //   they know the victim process's access patterns of procfs they could
    //   probably make an educated guess, but most files do not have stable
    //   inode numbers in procfs.
    //
    // * An attacker can no longer bind-mount their own fdinfo directory with
    //   just a buch of handles to "/proc" open (assuming the attacker is trying
    //   to spoof "mnt_id"), because the inode numbers won't match.
    //
    //   They also can't really fake inode numbers in real procfs fdinfo files,
    //   so they would need to create fake fdinfo files using individual file
    //   arbitrary-data gadgets (like /proc/self/environ). However, every
    //   program only has one environment so they would need to create a new
    //   child process for every fd they are trying to attack simultaneously
    //   (and accurately update their environment data to avoid detection).
    //
    // This isn't perfect protection by any means, but it's probably the best we
    // can do for very old kernels (given the constraints). At the very least,
    // it makes exploitation _much_ harder than if we didn't do anything at all.
    let actual_ino: u64 = fd.metadata().wrap("get inode number of fd")?.ino();

    /* ... */
}

% rustfmt +nightly --config=wrap_comments=true --check src/utils/fdinfo.rs

Diff in /home/cyphar/tmp/foo.rs:20:
     // our file descriptor. This makes attacks harder (if not near impossible,
     // outside of very constrained situations):
     //
-    // * An attacker would probably struggle to always accurately guess the
-    //   inode number of files that the process is trying to operate on. Yes, if
-    //   they know the victim process's access patterns of procfs they could
-    //   probably make an educated guess, but most files do not have stable
-    //   inode numbers in procfs.
+    // * An attacker would probably struggle to always accurately guess the inode
+    //   number of files that the process is trying to operate on. Yes, if they know
+    //   the victim process's access patterns of procfs they could probably make an
+    //   educated guess, but most files do not have stable inode numbers in procfs.
     //
-    // * An attacker can no longer bind-mount their own fdinfo directory with
-    //   just a buch of handles to "/proc" open (assuming the attacker is trying
-    //   to spoof "mnt_id"), because the inode numbers won't match.
+    // * An attacker can no longer bind-mount their own fdinfo directory with just a
+    //   buch of handles to "/proc" open (assuming the attacker is trying to spoof
+    //   "mnt_id"), because the inode numbers won't match.
     //
     //   They also can't really fake inode numbers in real procfs fdinfo files,
     //   so they would need to create fake fdinfo files using individual file

[matthewhughes934]

@rustbot claim