Page MenuHomePhabricator

[lldb] Enable C++14 when evaluating expressions in a C++14 frame
ClosedPublic

Authored by teemperor on Wed, May 20, 9:18 AM.

Details

Summary

Currently we never enable C++14 in the expression evaluator. This enables it when the language of the program is C++14.

It seems C++17 and so on isn't yet in any of the language enums (and the DWARF standard it seems), so C++17 support will be a follow up patch.

Diff Detail

Event Timeline

teemperor created this revision.Wed, May 20, 9:18 AM
This revision is now accepted and ready to land.Wed, May 20, 9:42 AM
labath accepted this revision.Wed, May 20, 11:31 PM

Looks good. Technically, the term "language of the program" is not very well defined, as a single application can contain a mixture of various languages and their revisions. IIRC, what actually happens here is that we pick the language from the currently selected frame.

teemperor retitled this revision from [lldb] Enable C++14 when evaluating expressions in a C++14 program to [lldb] Enable C++14 when evaluating expressions in a C++14 frame.Fri, May 22, 2:26 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFri, May 22, 3:01 AM
shafik added a subscriber: shafik.Fri, May 22, 10:34 AM
shafik added inline comments.
lldb/test/API/lang/cpp/standards/cpp14/TestCPP14Standard.py
19

It would be worth it to add a more complete set of C++14 tests. p1319r0 covers the C++11 to C++14 differences.

Especially ones that may not work so we can file bugs for these and track them.

It seems C++17 and so on isn't yet in any of the language enums (and the DWARF standard it seems), so C++17 support will be a follow up patch.

Yes and that may point to a problem with this approach. IIRC, there is — on purpose — no C++17 language constant because the committee didn't see the need to differentiate it in DWARF, since all features were additive and could be described through specific C++17-related attributes.

It seems C++17 and so on isn't yet in any of the language enums (and the DWARF standard it seems), so C++17 support will be a follow up patch.

Yes and that may point to a problem with this approach. IIRC, there is — on purpose — no C++17 language constant because the committee didn't see the need to differentiate it in DWARF, since all features were additive and could be described through specific C++17-related attributes.

That is also problematic b/c you can still compile in C++17 mode but not use any C++17 specific constructs and yet expect LLDB to act as-if.

teemperor marked an inline comment as done.Fri, May 22, 3:32 PM

It seems C++17 and so on isn't yet in any of the language enums (and the DWARF standard it seems), so C++17 support will be a follow up patch.

Yes and that may point to a problem with this approach. IIRC, there is — on purpose — no C++17 language constant because the committee didn't see the need to differentiate it in DWARF, since all features were additive and could be described through specific C++17-related attributes.

Interesting, so DWARF will do 11, 14, <skip>, 20? And 17 will presumably be encoded as 14 in DWARF?

lldb/test/API/lang/cpp/standards/cpp14/TestCPP14Standard.py
19

We're only checking that the right Clang language standard was set, not Clang's C++ features related to that set standard (which should be and probably already is a test in Clang).

max-kudr removed a subscriber: max-kudr.Fri, May 22, 3:39 PM
shafik added inline comments.Fri, May 22, 3:45 PM
lldb/test/API/lang/cpp/standards/cpp14/TestCPP14Standard.py
19

Well, yes and no. We have seen features that should work because clang supports it but don't because of other reasons such as variadic templates and structured bindings. So just because clang supports it does not mean it won't break in expressions because of some other reason.