On Wed, Oct 23, 2024 at 5:00 AM Jonathan Wakely via SG15
<sg15_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.

Oh! Wait...

> 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.

Thank you for that explanation! I didn't catch anything in the paper
explaining that it was proposing two interfaces into the compiler's
diagnostic systems and a somewhat orthogonal feature for
non-diagnostic printing at compile time, so I was under the impression
this was about three interfaces into the diagnostic system and
couldn't make sense of this one.

> 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

Yeah, now that I understand this feature not to be about diagnostics
directly but about generalized printing at compile time, this makes a
lot more sense and is something I think our users would find useful.
Given the lack of native debugger support for constant expressions, I
see why folks are so strongly in favor of it. That addresses my
reservations with the constexpr_print_str function -- thank you!

~Aaron