This is an archive of the discontinued LLVM Phabricator instance.

Fix inconsistent availability attribute message string literal check.
ClosedPublic

Authored by nigelp-xmos on Nov 25 2020, 8:43 AM.

Details

Summary

Function Parser::ParseAvailabilityAttribute checks that the message string of
an availability attribute is not a wide string literal. Test case
clang/test/Parser/attr-availability.c specifies that a string literal is
expected.

The code checked that the first token in a string concatenation is a string
literal, and then that the concatenated string consists of 1-byte characters.
On a target where wide character is 1 byte, a string concatenation "a" L"b"
passes both those checks, but L"b" alone is rejected. More generally, "a" u8"b"
passes the checks, but u8"b" alone is rejected.

So check isAscii() instead of character size.

Diff Detail

Event Timeline

nigelp-xmos created this revision.Nov 25 2020, 8:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 25 2020, 8:43 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
nigelp-xmos requested review of this revision.Nov 25 2020, 8:43 AM

Alternatively, if all 1-byte-character strings are acceptable, should I remove the check that the first token is a string literal, and omit the failing test case on XCore?

Run clang-format

Run clang-format

aaron.ballman accepted this revision.Dec 4 2020, 8:57 AM
aaron.ballman added a subscriber: aaron.ballman.

I think this is a good change but would point out that the diagnostic message is pretty confusing as-is. u8"a" is a string literal, so saying that a string literal is expected doesn't make sense. We may want to consider either supporting string literals more generally or changing the diagnostic. The mixing of adjacent string literals with prefixes is something I don't think we need/want to support (esp as both C and C++ are making efforts to make such code ill-formed anyway), but I don't see why we should reject message=u8"whatever" (or any of the other prefixes).

However, that's an orthogonal issue and this is good incremental progress, so LGTM!

This revision is now accepted and ready to land.Dec 4 2020, 8:57 AM

Many thanks for review and approval. Please could it be committed as I do not have commit access? (I will request.)

aaron.ballman closed this revision.Dec 8 2020, 9:35 AM

Many thanks for review and approval. Please could it be committed as I do not have commit access? (I will request.)

Happy to do so! I've committed on your behalf in 27ea7d0a6e0dc51e0214707bcc265fa6f9dc9bc6, thank you for the patch.