Unrecognized literal string suffixes

[j-cortial]

Checklist

• This problem exists even with the setting "C_Cpp.enhancedColorization": "Disabled"

The code with a problem is:

#include <string>
#include <string_view>

using namespace std::literals::string_view_literals;
using namespace std::literals::string_literals;

const auto view = "Hello"sv;
const auto owned = "Hello"s;

It looks like:

It should look like:

The suffixes "s" and "sv" should be highlighted.

Reference

https://en.cppreference.com/w/cpp/language/user_literal

[jeff-hykin]

User literals should be covered (the ref link) but I was unaware of std literals till now.

https://en.cppreference.com/w/cpp/string/basic_string_view/operator%22%22sv

https://en.cppreference.com/w/cpp/string/basic_string/operator%22%22s

https://en.cppreference.com/w/cpp/numeric/complex/operator%22%22i

https://en.cppreference.com/w/cpp/symbol_index/literals

[j-cortial]

Numeric user-defined literal suffixes are already covered, but not suffixes for strings and characters.
I am currently working on a PR to fix that.

All literal suffixes are "user-defined", even the ones provided by the standard library. However, the suffixes that do not start with an underscore are reserved for use by the standard library (such as std::string operator""s), and they should not be defined in a program.

By the way, I think the tag used for numeric literal suffixes (keyword.other.unit.user-defined) could be improved, since there no intrinsic notion of unit (except in some special cases, for std::chrono for instance) for literals in general.
I would rather suggest keyword.other.suffix.user-defined.numeric (and keyword.other.suffix.user-defined.reserved.numeric for those not starting with an underscore) for instance.
The same remark applies to language-defined suffixes such as keyword.other.unit.suffix.floating-point and friends, since they specify a type, not a unit.

[jeff-hykin]

Sadly the keyword.other.unit is not done because it is accurate, but because keyword.other.unit is used by other languages and themes, while inventing a new scope means absolutely no existing theme is going to highlight it.

Ex: CSS highlighting

However we can do both; "keyword.other.unit keyword.other.suffix.user-defined.numeric" will let it default to the keyword.other.unit color, but be overridden for super-customized themes that actually know about the existance of keyword.other.suffix.user-defined.numeric

[j-cortial]

My proposal in the PR: #622

[jeff-hykin]

published with v1.17.3! thanks for handling this