This is an archive of the discontinued LLVM Phabricator instance.

[clang][ExprConst] Use call source range for 'in call to' diags
ClosedPublic

Authored by tbaeder on Jul 29 2023, 9:03 PM.

Details

Summary

Before:

array.cpp:74:15: error: static assertion expression is not an integral constant expression
   74 | static_assert(ints(1, div(true, false), 2, div(false, true)) == 1, "");
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.cpp:68:12: note: division by zero
   68 |   return 1 / (int)b;
      |            ^
array.cpp:74:23: note: in call to 'div(true, false)'
   74 | static_assert(ints(1, div(true, false), 2, div(false, true)) == 1, "");
      |                       ^
1 error generated.

After:

array.cpp:74:15: error: static assertion expression is not an integral constant expression
   74 | static_assert(ints(1, div(true, false), 2, div(false, true)) == 1, "");
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.cpp:68:12: note: division by zero
   68 |   return 1 / (int)b;
      |            ^
array.cpp:74:23: note: in call to 'div(true, false)'
   74 | static_assert(ints(1, div(true, false), 2, div(false, true)) == 1, "");
      |                       ^~~~~~~~~~~~~~~~

As you can see I have a test case, but I didn't attach it in test/Misc/constexpr-source-ranges.cpp because I can't get -fdiagnostics-print-source-range-info to actually print anything for them.

Diff Detail

Event Timeline

tbaeder created this revision.Jul 29 2023, 9:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2023, 9:03 PM
tbaeder requested review of this revision.Jul 29 2023, 9:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2023, 9:03 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

As you can see I have a test case, but I didn't attach it in test/Misc/constexpr-source-ranges.cpp because I can't get -fdiagnostics-print-source-range-info to actually print anything for them.

That's odd; have you investigated what's going on/filed an issue?

The changes LG, but the lack of test coverage gives me pause.

tbaeder updated this revision to Diff 545934.EditedAug 1 2023, 12:02 AM

As you can see I have a test case, but I didn't attach it in test/Misc/constexpr-source-ranges.cpp because I can't get -fdiagnostics-print-source-range-info to actually print anything for them.

That's odd; have you investigated what's going on/filed an issue?

I have thoroughly investigated the aforementioned issue and found the cause: I am blind.

@hazohelet I changed this to just return CallExpr->getSourceRange() and to not save a source range separately. Can you give this a look please?

@hazohelet I changed this to just return CallExpr->getSourceRange() and to not save a source range separately. Can you give this a look please?

I was thinking about removing CallLoc some time ago, and concluded that we shouldn't.
Destructor calls are usually not explicitly written by the user, so CallExpr is set to null. CallLoc is often set to the declaration location (https://github.com/llvm/llvm-project/blob/97cddb78502eee583b5f4ee02c59b7156398587f/clang/lib/AST/ExprConstant.cpp#L703-L708).
So we'll lose this information if we are to remove CallLoc from the stack frame, and it seems to be the reason for the test failures.

About getting source range from CallExpr->getSourceRange, I don't see any obvious problems. All explicitly-written function calls should have its AST in CallExpr field.
So using the CallLoc for the diagnostics location and CallExpr->getSourceRange for the source range would do the trick.

tbaeder updated this revision to Diff 545980.Aug 1 2023, 2:40 AM
aaron.ballman accepted this revision.Aug 8 2023, 9:11 AM

LGTM but please give a day or two for @hazohelet to weigh in.

This revision is now accepted and ready to land.Aug 8 2023, 9:11 AM

We need some tests for dtors because they are handled differently from other functions.
I think the current ExprConstant part would not cover the explicitly-called dtors because the HandleDestructorImpl only has access to CallLoc and not source range.
Also new interpreter seems to point to the wrong source location on implicitly-called dtor.
Link: https://godbolt.org/z/1a6GW47eG
I think it's good to have a fix for it in this patch if it's not too complicated.

My previous comment "All explicitly-written function calls should have its AST in CallExpr field." was wrong for destructors. Sorry for the confusion.

tbaeder updated this revision to Diff 548520.Aug 9 2023, 2:07 AM

We need some tests for dtors because they are handled differently from other functions.
I think the current ExprConstant part would not cover the explicitly-called dtors because the HandleDestructorImpl only has access to CallLoc and not source range.
Also new interpreter seems to point to the wrong source location on implicitly-called dtor.
Link: https://godbolt.org/z/1a6GW47eG
I think it's good to have a fix for it in this patch if it's not too complicated.

Yeah I know, there's a FIXME comment in the tests somewhere and it's on my list.

hazohelet accepted this revision.Aug 9 2023, 5:39 AM

I think it would be helpful to point to the subobject source range when diagnosing errors in subobject dtors, so I left some suggestions.
Otherwise this LGTM. Thanks!

clang/lib/AST/ExprConstant.cpp
6653
6672

It's not the problem of this patch, but it might be nice to have CXXBaseSpecifier::getTypeSourceRange or alike because this is an interesting source range.

While both of those suggestions are probably improvements (I haven't checked), they also seem out of scope for this patch. This is just adding source ranges. We can improve them later (and add better tests for them at that point).

cjdb accepted this revision.Aug 9 2023, 10:34 AM

While both of those suggestions are probably improvements (I haven't checked), they also seem out of scope for this patch. This is just adding source ranges. We can improve them later (and add better tests for them at that point).

That makes sense to me.