This is an MSVC bug. Per [lex.string]p13, "If one string literal has no encoding-prefix, it is treated as a string literal of the same encoding-prefix as the other operand."

It's not clear to me how practical it would be for us to work around this bug. =(

This is a really common Windows idiom, so I think we should try to support it. It doesn't seem too hard.

Wrap:
_T("really long string")

To:
_T("really")
_T("long")
_T("string")

And we should recognize it by finding a string literal inside of a '_T(...)' like thing.

What exactly is a "_T(...)" like thing? If we are looking for exactly for the identifier _T, this could work. Otherwise, I think we would have to be absolutely sure that it is a macro defined as "L##x", because basically everything else will break with this change.

Seems like a big risk to work around a compiler bug. Alternatively, we could detect this pattern and not insert a break.

What exactly is a "_T(...)" like thing? If we are looking for exactly for
the identifier _T, this could work. Otherwise, I think we would have to be
absolutely sure that it is a macro defined as "L##x", because basically
everything else will break with this change.

Yea, I was thinking to look for exactly '_T' preceding a parenthesis.

Seems like a big risk to work around a compiler bug. Alternatively, we could
detect this pattern and not insert a break.

My impression is that this is not dissimilar to the _(...) trick used in gettext in that it shows up in lots of places. That's why I thought it might be reasonable and worthwhile to do.... Fixing the compiler bug is both unlikely and slow.

As I said, as long as we are looking for exactly "_T", I don't see problems. If not, I would prefer not introducing a line break (which would also "solve" this bug).

This is an MSVC bug. Per [lex.string]p13, "If one string literal has no
encoding-prefix, it is treated as a string literal of the same
encoding-prefix as the other operand."

It's not clear to me how practical it would be for us to work around this
bug. =(

This behavior conforms with the C++03 standard ([lex.string]p3):
"In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined."

AFAICT this is fixed by Alex's r190804.