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

[teemperor]

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.

[JDevlieghere]

Dope

[labath]

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.

[shafik]

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.

[max-kudr]

Hello,

I suppose this commit broke Windows LLDB tests (http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/16486 -> logs: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/16486/steps/test/logs/stdio). Can you please fix or rollback it?

Thank you!

[aprantl]

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.

[shafik]

In D80308#2051624, @aprantl wrote:

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]

In D80308#2051624, @aprantl wrote:

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).

[shafik]

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.