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



I think a tag on error sort of makes sense. People will want to control and
> disable egregious uses of user generated diagnostics.
>
> Beyond that, I think what the paper proposes makes sense - it is a fairly
> minimal proposal, as it should be.
> Any more granularity over the diagnostics engine should either remain in
> the realm of compiler extensions, or require a lot more usage experience.
>
> And we sort of need this feature to have any chance of making reflection
> remotely maintainable.
>
>
>
>>
>> ~Aaron
>>
>> >
>> > Barry
>> _______________________________________________
>> SG15 mailing list
>> SG15_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>