Optimize `decltype(T{})` to `T` in compiler error messages

[mpusz]

In many cases clang generates an error like:

note: because 'implicitly_convertible(kind_of_<decltype(struct time{{{}}})>{{{}, {}}}, kind_of_<decltype(derived_quantity_spec<power<length, 2>, per<time> >{{{}, {{}}}})>{{{}}})' evaluated to false

besides the #88502 issue the decltype(T{}) also does not help in readability here. The above message could be simplified to:

note: because 'implicitly_convertible(kind_of_<struct time>{}, kind_of_<derived_quantity_spec<power<length, 2>, per<time> >>{})' evaluated to false

Those two issues would help libraries like mp-units provide users with much easier-to-understand diagnostics.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Mateusz Pusz (mpusz)

In many cases clang generates an error like: ``` note: because 'implicitly_convertible(kind_of_<decltype(struct time{{{}}})>{{{}, {}}}, kind_of_<decltype(derived_quantity_spec<power<length, 2>, per<time> >{{{}, {{}}}})>{{{}}})' evaluated to false ``` besides the #88502 issue the `decltype(T){}` also does not help in readability here. The above message could be simplified to: ``` note: because 'implicitly_convertible(kind_of_<struct time>{}, kind_of_<derived_quantity_spec<power<length, 2>, per<time> >>{})' evaluated to false ``` Those two issues would help libraries like mp-units provide users with much easier-to-understand diagnostics.

[shahryarkiani]

Hi, I'd like to work on this.

[akrisfx]

Hi, I'd like to work on that too

[akshaykumars614]

@mpusz, can you provide a testcase for this?

[mpusz]

Unfortunately, I do not have time to simplify this, but here is the error message from the first post in this thread: https://godbolt.org/z/9qb1rjxe5.

[nfrmtk]

Hello, @mpusz. I am confused about this issue: title says, that goal is to replace all occurrences of decltype('something'){} with 'something'. But example you gave doesn't do that: it

1. replaces decltype(T{}) with T
2. replaces arbitrary correct '{' and '}' sequence with just '{}'

Also, it is incorrect to do what is stated in the title because decltype(1){} != 1. So, can you clarify the final goal of the issue?

[mpusz]

Sorry, I made a typo in the title and description.

[Rajveer100]

@dwblaikie I am not sure if the below approach is valid:

Under diagnoseWellFormedUnsatisfiedConstraintExpr:

void simplifyNestedParentheses(Expr *E) {
  if (!E)
    return;

  if (auto *Paren = dyn_cast<ParenExpr>(E)) {
    Expr *Inner = Paren->getSubExpr();
    if (auto *InnerParen = dyn_cast<ParenExpr>(Inner)) {
      E = InnerParen->getSubExpr();
      simplifyNestedParentheses(InnerParen);
      return;
    }
  }

  for (Stmt *Child : E->children()) {
    if (auto *ChildExpr = dyn_cast<Expr>(Child)) {
      simplifyNestedParentheses(ChildExpr);
    }
  }
}

We could call this right before note_atomic_constraint_evaluated_to_false.

[nfrmtk]

Hello @mpusz I have a questions on second part of task, where desired result is to remove extra curly brackets, that indicate default construction of a variable. Consider following example:

struct S{
  struct S1{
    int num1;
  } s1;
  struct S2{
    int num2;
  } s2;
}; 
S s{{{}}, {{1}}};

Is it intended to optimise first two nested braces into 1?

[mpusz]

I am not a clang designer or developer, so it is not up to me to decide how it should work in this case. In my case, all types are empty tag types but still have plenty of nested braces.

BTW, "the second part of the task" is #88502 as mentioned in the description above.