diff options
author | erer1243 <erer1243@gmail.com> | 2024-03-08 21:29:33 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-03-09 10:29:33 +0800 |
commit | e1405e4f71c899420ebf8262d5e9745598419df8 (patch) | |
tree | f80400d8e7a0a41e48ad22911d13409f181dd731 /clang/lib/CodeGen/CodeGenFunction.cpp | |
parent | 2709bafbfe54b75003c60a950605194d6a3c9776 (diff) | |
download | llvm-e1405e4f71c899420ebf8262d5e9745598419df8.zip llvm-e1405e4f71c899420ebf8262d5e9745598419df8.tar.gz llvm-e1405e4f71c899420ebf8262d5e9745598419df8.tar.bz2 |
[llvm-c] Add C API methods to match size_t ConstantDataArray C++ API signatures (#84433)
Adds `LLVMConstStringInContext2` and `LLVMConstString2`, which are
identical to originals except that they use `size_t` for length. This is
a clone of
https://github.com/llvm/llvm-project/commit/35276f16e5a2cae0dfb49c0fbf874d4d2f177acc
and is needed for https://github.com/rust-lang/rust/pull/122000.
As an aside, the issue of 32 bit overflow on constants is present in the
C++ APIs as well. A few classes, e.g. `ConstantDataArray` and
`ConstantAggregateZero`, can hold 64-bit ArrayTypes but their length
accessors return 32-bit values. This means the same issue from the
original Rust report is also present in LLVM itself. Would it be a
reasonable goal to update all of these length methods & types to be
uint64_t, or would that be too breaking? Alternatively, we could use
safe fallible casts instead of implicit ones inside the accessors (if an
overflow does happen, the solution would be to use
`MyValue->getType()->getArrayNumElements()` instead).
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions