[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