[all-commits] [llvm/llvm-project] 8c6f30: [clang] Introduce "binary" StringLiteral for #embe...
Mariya Podchishchaeva via All-commits
all-commits at lists.llvm.org
Thu Mar 20 05:02:50 PDT 2025
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 8c6f309023a9c5b6d8488e89ed0be8da7d117a68
https://github.com/llvm/llvm-project/commit/8c6f309023a9c5b6d8488e89ed0be8da7d117a68
Author: Mariya Podchishchaeva <mariya.podchishchaeva at intel.com>
Date: 2025-03-20 (Thu, 20 Mar 2025)
Changed paths:
M clang/include/clang/AST/Expr.h
M clang/lib/AST/Expr.cpp
M clang/lib/Parse/ParseInit.cpp
M clang/lib/Sema/SemaInit.cpp
A clang/test/Preprocessor/embed_constexpr.c
Log Message:
-----------
[clang] Introduce "binary" StringLiteral for #embed data (#127629)
StringLiteral is used as internal data of EmbedExpr and we directly use
it as an initializer if a single EmbedExpr appears in the initializer
list of a char array. It is fast and convenient, but it is causing
problems when string literal character values are checked because #embed
data values are within a range [0-2^(char width)] but ordinary
StringLiteral is of maybe signed char type.
This PR introduces new kind of StringLiteral to hold binary data coming
from an embedded resource to mitigate these problems. The new kind of
StringLiteral is not assumed to have signed char type. The new kind of
StringLiteral also helps to prevent crashes when trying to find
StringLiteral token locations since these simply do not exist for binary
data.
Fixes https://github.com/llvm/llvm-project/issues/119256
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list