Open JohelEGP opened 1 week ago
Some more code:
if member_objects.contains(first*.arguments, :(x) = x.name()) { // Safe but rejected.
if member_objects.contains(first*.arguments, :(x) = (x.name())) { // Drowning in parentheses.
if member_objects.contains(first*.arguments, :(x) -> _ = x.name()) { // The unterse.
for std::views::iota(0, 5) do (i) test(count_n(i), :(x) = x.std::min(i$)); // Safe but rejected.
for std::views::iota(0, 5) do (i) test(count_n(i), :(x) = (x.std::min(i$))); // Drowning in parentheses.
for std::views::iota(0, 5) do (i) test(count_n(i), :(x) = std::min(x, i$)); // Mathematically correct.
I personally do not like further overloading parentheses (https://github.com/hsutter/cppfront/issues/542#issuecomment-1635897970).
I'm afraid I have mixed two issues in one. The suggestion to improve what's rejected. And the presentation of diagnostics in general.
Following the comment a bit above: https://github.com/hsutter/cppfront/blob/68b716abe3e4b623e875d68a2b9b3f0efcd39b45/source/to_cpp1.h#L2411-L2412 I parenthesized the expression, which made it it OK.
Oh, but a parenthesized expression is a postfix-expression.
//G primary-expression:
//G [...]
//G '(' expression-list ','? ')'
//G [...]
//G
//G postfix-expression:
//G primary-expression
//G [...]
So maybe my workaround works unintendedly.
If you do not use UFCS, it starts to work. https://cpp2.godbolt.org/z/vePsbM7bj
It seems that for a regular function call the analysis is not as elaborate. In order to get a better understanding, I would suggest an improved reproducer. E.g. a pure cpp2 case, an object with different functions with different returns, and multiple lines that demonstrate what works and what not works.
Title: Improving diagnostics with "Reasons:" and "Suggestions:".
Description:
Updating my code, I kept hitting: https://github.com/hsutter/cppfront/blob/68b716abe3e4b623e875d68a2b9b3f0efcd39b45/source/to_cpp1.h#L2433 I'm doubting the usefulness of this error as it is.
It's preventing me from writing
which copies
v
, a vector, into a point fromwindow
tov
.Following the comment a bit above: https://github.com/hsutter/cppfront/blob/68b716abe3e4b623e875d68a2b9b3f0efcd39b45/source/to_cpp1.h#L2411-L2412 I parenthesized the expression, which made it it OK.
Can we update these checks?
copy
seems to be as safe as any local variable (https://cpp2.godbolt.org/z/Y8nahPjhh works from Clang 12 and GCC 10 in C++20, to theirHEAD
versions in C++26).in
param
in_ref
.in
param.X()
(expr)
ifparam
is not part of the return value, andin_ref param
otherwise (maybe note thatin
can optimize to pass by copy).copy
param
copy
param.X()
move
param
-> _
, or-> cpp1_rvalue_ref<ParamType>
, or allow-> forward_ref _
and also suggest it.move
param.X()
(expr)
ifparam
is not part of the return value.Sometimes, I'm left wondering the reason for some of the rejections. It'd be nice to centralize the documentation of how Cpp2 features obsolete guidance. That would make it easier to challenge some of decisions, and maybe even help notice further improvements.
For example, given the table above:
in
param
in
can optimize to pass by copy. Usein_ref
instead.in
param.X()
param
might live in the resulting value of the expression.copy
param
param
.copy
param.X()
param
.move
param
move
param.X()
param
might live in the resulting value of the expression.In fact, this reminds me of some talk(s) where the speaker(s) mention how the compilers of other programming languages have much nicer diagnostics. Something like how those compilers are a friend in the development journey rather than a tool.
Taking all of the above, consider the following Cpp2 code fragment and the contents of a desired diagnostic (https://cpp2.godbolt.org/z/n85qhcjbj).
PS: I don't think this is a [SUGGESTION].