Re: [PATCH] .gitignore: ignore rustc long type txt files

Re: [PATCH] .gitignore: ignore rustc long type txt files

[Miguel Ojeda]

On Thu, May 21, 2026 at 12:29 PM Manos Pitsidianakis
<manos@pitsidianak.is> wrote:
>
> When rustc prints an error containing a long type that doesn't fit in a
> line, it will write the whole thing in a .txt file and print messages
> like:
>
>   note: the full type name has been written to
>   'path/to/subsystem/module_name.long-type-11621316855315349594.txt
>
> Long types like core::result::Result<core::pin::Pin<Box<_, Kmalloc,
> kernel::error::Error>: pin_init::PinInit<Box<_, Kmalloc>, _> are common
> during development, so add a gitignore entry.
>
> Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>

Cc'ing Nathan, Nicolas and Kbuild -- I considered whether deleting
these in e.g. `distclean`. They are only error artifacts, i.e. the
build system doesn't create these intentionally -- they come from the
Rust compiler in a minority of error cases (where type names are
long).

So end users shouldn't see them anyway, so I am not sure what the policy is.

In any case, putting these in `.gitignore` shouldn't hurt, and they
are definitely not intended to be committed, so it makes sense
regardless of the cleaning. Thus I will commit it with these notes
unless someone shouts:

    [ Depending on the compiler version and the kind of error, there are
      two possible spellings -- copying them here for reference:

          = note: the full name for the type has been written to
'...long-type-...txt'
          = note: the full type name has been written to '...long-type-...txt'

        - Miguel ]

    [ Moved the lines closer to the existing rust-analyzer one. - Miguel ]

I also wondered about `--verbose` (which probably we don't want to
enable unconditionally) and `-Zwrite-long-types-to-disk=no` (which
could be possible as a nice middle ground if kernel developers prefer
to avoid the files unconditionally -- I asked upstream out of
curiosity if that or something similar is intended to be stable at
some point).

Thanks!

Cheers,
Miguel

Re: [PATCH] .gitignore: ignore rustc long type txt files

[Nathan Chancellor]

On Thu, May 28, 2026 at 01:53:46PM +0200, Miguel Ojeda wrote:
> On Thu, May 21, 2026 at 12:29 PM Manos Pitsidianakis
> <manos@pitsidianak.is> wrote:
> >
> > When rustc prints an error containing a long type that doesn't fit in a
> > line, it will write the whole thing in a .txt file and print messages
> > like:
> >
> >   note: the full type name has been written to
> >   'path/to/subsystem/module_name.long-type-11621316855315349594.txt
> >
> > Long types like core::result::Result<core::pin::Pin<Box<_, Kmalloc,
> > kernel::error::Error>: pin_init::PinInit<Box<_, Kmalloc>, _> are common
> > during development, so add a gitignore entry.
> >
> > Signed-off-by: Manos Pitsidianakis <manos@pitsidianak.is>
> 
> Cc'ing Nathan, Nicolas and Kbuild -- I considered whether deleting
> these in e.g. `distclean`. They are only error artifacts, i.e. the
> build system doesn't create these intentionally -- they come from the
> Rust compiler in a minority of error cases (where type names are
> long).
> 
> So end users shouldn't see them anyway, so I am not sure what the policy is.

I view these more like build artifacts since the messages in them are
really only relevant to a specific build instance, so I would probably
clean them up with 'clean' over 'mrproper' / 'distclean'. But if they are in
.gitignore, I don't think it matters too much though, but it does feel
like they should be cleaned up with at least 'distclean'.

-- 
Cheers,
Nathan

Re: [PATCH] .gitignore: ignore rustc long type txt files

[Miguel Ojeda]

On Thu, May 28, 2026 at 10:36 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> I view these more like build artifacts since the messages in them are
> really only relevant to a specific build instance, so I would probably
> clean them up with 'clean' over 'mrproper' / 'distclean'. But if they are in
> .gitignore, I don't think it matters too much though, but it does feel
> like they should be cleaned up with at least 'distclean'.

Sounds good, thanks Nathan!

Then let's land this one and we can discuss that on top. I have
created a "good first issue" for that:

  https://github.com/Rust-for-Linux/linux/issues/1236

Cheers,
Miguel