On Wed, 23 Oct 2024 at 10:00, Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Wed, 23 Oct 2024, 07:33 Corentin Jabot via SG15, <sg15_at_[hidden]>
> wrote:
>
>>
>>
>> On Wed, Oct 23, 2024 at 3:14 AM Aaron Ballman via SG15 <
>> sg15_at_[hidden]> wrote:
>>
>>> On Tue, Oct 22, 2024 at 1:46 PM Barry Revzin <barry.revzin_at_[hidden]>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Oct 16, 2024 at 8:40 AM Aaron Ballman <aaron_at_[hidden]>
>>> wrote:
>>> >>
>>> >> On Wed, Oct 16, 2024 at 6:10 AM Jonathan Wakely <cxx_at_[hidden]>
>>> wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tue, 15 Oct 2024 at 18:53, Aaron Ballman via SG15 <
>>> sg15_at_[hidden]> wrote:
>>> >> >>
>>> >> >> Thanks! FWIW, users do want this sort of capability, but the fact
>>> that
>>> >> >> no implementation has yet to add a feature with bells and whistles
>>> is
>>> >> >> because the problem is not easy to solve. I'm highly skeptical that
>>> >> >> this is something WG21 should be standardizing at all currently;
>>> it's
>>> >> >> firmly in the realm of QoI and different implementations have
>>> >> >> different needs (and our needs evolve over time). The only form of
>>> the
>>> >> >> feature I would consider supporting would be one that accepts the
>>> >> >> message to be printed during constant evaluation and nothing else.
>>> >> >> Anything with more bells and whistles will be problematic in
>>> practice.
>>> >> >>
>>> >> >> Practical implementability problems include:
>>> >> >> * Different implementations have different severities for
>>> diagnostics
>>> >> >> (error, warning, note, remark, no severity distinctions, etc)
>>> >> >
>>> >> >
>>> >> > We already have a distinction between #error and #warning, how is
>>> this any different?
>>> >> > constexpr_print just outputs a message at compile time (which
>>> you've said is fine).
>>> >>
>>> >> Because it adds another layer of distinction (constexpr_print_str)
>>> >> which may or may not make sense to any given implementation. In Clang
>>> >> specifically, is that a note or a remark? (There are problems with
>>> >> whichever one we pick, so it'd probably be an entirely new thing, but
>>> >> none of our users have actually asked for something like that, at
>>> >> least that I'm aware of.)
>>> >
>>> >
>>> > I've been thinking of how you expect me to respond to this, and I'm
>>> still not entirely sure. You're not aware of ANY of your users having asked
>>> for something like this? Not even the user who is asking for something like
>>> this so hard that he wrote a paper, took it through several groups, and got
>>> strong (nearly unanimous) consensus for its adoption?
>>>
>>> There are no feature requests for such a thing on Clang's issue
>>> tracker, nor was there a question or RFC on our Discourse forums, and
>>> no PRs were opened trying to implement the feature, and I couldn't
>>> find any blog posts about such a feature for, etc. So yes, I'm not
>>> aware of any users asking for something like constexpr_print despite
>>> there being several instances where users have asked for things like
>>> directly emitting errors or warnings.
>>>
>>
>> FYI, I pretty much agree with all the points that Jonathan made.
>> As long as there is no requirement put on the implementation on how the
>> warnings are produced and controlled, I have personally no concern with
>> this feature in Clang.
>> I think the tag is useful, as long as we can decide to use it however we
>> want - if we decide to do something with it (and we certainly don't want to
>> affect existing diagnostic groups and flags - user creativity should be
>> contained)
>> I certainly agree that "print" is less useful than warning and error (We
>> basically never have non-error non-warning diagnostics - very much
>> purposefully ) - maybe getting rid of print in the first iteration of this
>> paper would help increase consensus.
>>
>
> It has had very strong consensus in EWG at every stage, and print is the
> form I wanted first. Debugging template instantiations and constexpr
> functions is hard without it. Sure, you can force a warning instead if we
> got constexpr_warning, but that's more awkward if using -Werror.
>
> My use case for constexpr_print is for "interactive" development during
> compile-edit-debug cycles. You add some prints, but then take them out
> again once you've understood how the code is compiling. So IMHO it really
> doesn't matter how that output is displayed. It could even go to a separate
> file.
>
> It doesn't really need to fit into the usual rigid structure for
> diagnostic messages, because typically it won't be consumed by tools or
> retained in logs. Constexpr print will be added to the code temporarily and
> then removed again (or commented out). It's more transient.
>
> FWIW g++ does already have this kind of output, it's actually the default
> for cc1plus to spit out the name of every function template as it's
> instantiated! The g++ driver passes -quiet to the cc1plus compiler
> executable to suppress that output. I once developed a patch to add class
> template instantiations to the output, because I desperately wanted that
> functionality. Printing arbitrary messages would have been even better.
>
> Compiler developers might be able to just step through the compiler in a
> debugger to understand how your code is compiled, but mere mortals can't do
> that if they don't understand the compiler code and know where to add
> breakpoints.
>
> The existence of Templight* is clear evidence that clang users do want
> this! Templight is interactive gdb debugging and constexpr_print is printf
> debugging. Both have their place.
>
> *
> https://github.com/mikael-s-persson/templight?tab=readme-ov-file#templight-debugger
>

And https://cppinsights.io is another existence proof for "show me what the
compiler is doing as it compiles my code", and that's also built with clang
(or libclang). But minimizing your code so that you can upload it to an
interactive web-based tool isn't always practical (and not allowed for some
proprietary code that you shouldn't be uploading to third-party web
services). constexpr_print wouldn't do everything that cppinsights does,
but that's fine, it would be for more targeted uses where you are only
interested in tracing specific constant evaluations or template
instantiations (and unlike cppinsights, you could do `if (some condition)
constexpr_print("here")` to limit it to the cases you care about).

Being able to trace (parts of) a compilation directly with the compiler as
part of your normal compilation means you don't need a separate tool like
Templight or cppinsights. The demand for that seems clear to me, when
people have gone to the effort of implementing Templight and cppinsights
(and EDG implemented it in their compiler years ago).