Re: [PATCH] [v2] rust: introduce sfile macro for succinct code tracing

[Timur Tabi <ttabi@nvidia.com>]

On Wed, 2025-06-04 at 00:53 +0200, Miguel Ojeda wrote:
> On Tue, Jun 3, 2025 at 9:55 PM Timur Tabi <ttabi@nvidia.com> wrote:
> > 
> > +/// built-in file!() macro, which returns the full path of the current file.
> 
> This is missing a code span and it is still using a single sentence
> for the "short title".
> 
> > +/// ```
> > +/// pr_err!("{}:{}\n", sfile!(), line!());
> > +/// ```
> 
> Examples are built and tested, so please make sure they work -- this
> will likely fail to build, since `sfile!` is not imported nor in the
> prelude.
> 
> > +        assert!(FILE.is_ascii()); // .as_bytes() does not support non-ascii filenames
> 
> We generally avoid comments after a statement, instead we typically
> put them in the previous line.
> 
> Also: code span is missing, "ASCII", and we end them with periods.
> 
> > +        // Return the index of the last occurrence of `needle` in `haystack`,
> > +        // or zero if not found.  We can't use rfind() because it's not const (yet).
> > +        // Avoiding rfind() allows this macro to be evaluated at compile time.
> 
> The first sentence should be `///`, and the rest a comment. It also
> lacks code spans.

Ok, I think I got it this time.

> > +        // We use these unsafe functions because apparently indexing into
> > +        // a string using normal Rust methods is not completely const operation.
> 
> Hmm... I am confused about what this is trying to say. `rfind` is not
> const, but that does not imply "indexing into a string" is not const
> (what "indexing into a string" means here?)
> 
> Also, we should try to avoid "apparently". And what does "not
> completely const" mean here?

Sorry, I didn't really understand your explanation, and I guess I failed to summarize it.  I don't
know what "not completely const" means, either.

I don't understand why, when I use "&FILE[start..]", this compiles as inline:

	pr_err!("{}:{}\n", sfile!(), line!());

but this doesn't:

	const SFILE: &'static str = sfile!();

It seems to me that the second line is "more const" than the first line, if that makes any sense.  

What I was trying to say is that I need to use all those crazy unsafe calls so that the second line
works, but I can get away with just "&FILE[start..]" if I only cared about the first line.

> 
> By the way, please use the standard "[...]" for patch titles -- you
> can pass e.g. `-v2` to Git for that. (And ideally please provide `--base` too).

You mean you don't like [PATCH][V2]?  I've been doing that for 20 years, and this is the first time
anyone's complained.