* Re: [PATCH] .gitignore: ignore rustc long type txt files [not found] <20260521-rust-gitignore-long-types-txt-v1-1-5be5e6fa427c@pitsidianak.is> @ 2026-05-28 11:53 ` Miguel Ojeda 2026-05-28 20:36 ` Nathan Chancellor 0 siblings, 1 reply; 3+ messages in thread From: Miguel Ojeda @ 2026-05-28 11:53 UTC (permalink / raw) To: Manos Pitsidianakis, Nathan Chancellor, Nicolas Schier, Linux Kbuild mailing list Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, linux-kernel, rust-for-linux 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] .gitignore: ignore rustc long type txt files 2026-05-28 11:53 ` [PATCH] .gitignore: ignore rustc long type txt files Miguel Ojeda @ 2026-05-28 20:36 ` Nathan Chancellor 2026-05-28 21:08 ` Miguel Ojeda 0 siblings, 1 reply; 3+ messages in thread From: Nathan Chancellor @ 2026-05-28 20:36 UTC (permalink / raw) To: Miguel Ojeda Cc: Manos Pitsidianakis, Nicolas Schier, Linux Kbuild mailing list, Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, linux-kernel, rust-for-linux 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] .gitignore: ignore rustc long type txt files 2026-05-28 20:36 ` Nathan Chancellor @ 2026-05-28 21:08 ` Miguel Ojeda 0 siblings, 0 replies; 3+ messages in thread From: Miguel Ojeda @ 2026-05-28 21:08 UTC (permalink / raw) To: Nathan Chancellor Cc: Manos Pitsidianakis, Nicolas Schier, Linux Kbuild mailing list, Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross, Danilo Krummrich, linux-kernel, rust-for-linux 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-28 21:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260521-rust-gitignore-long-types-txt-v1-1-5be5e6fa427c@pitsidianak.is>
2026-05-28 11:53 ` [PATCH] .gitignore: ignore rustc long type txt files Miguel Ojeda
2026-05-28 20:36 ` Nathan Chancellor
2026-05-28 21:08 ` Miguel Ojeda
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox