| commit | 99718444c4f665a8633d9a0a01cee1dadb3443c1 | [log] [tgz] |
|---|---|---|
| author | Balázs Benics <108414871+balazs-benics-sonarsource@users.noreply.github.com> | Thu Sep 04 08:20:00 2025 +0200 |
| committer | GitHub <noreply@github.com> | Thu Sep 04 08:20:00 2025 +0200 |
| tree | 1ccb7c3dc8c3908eaaf3e8b4e37d96898d2ab4c1 | |
| parent | a23a5b06839011569590af5c9bbfb5197b24261b [diff] |
[analyzer] Canonicalize the Decls of FieldRegions (#156668) When calculating the offset of a FieldRegion, we need to find out which field index the given field refers to. Previously, if for some reason the field was not found, then the `Idx` passed to `Layout.getFieldOffset` was out of bounds and caused undefined behavior when dereferenced an out of bounds element in `ASTVector::FieldOffsets::operator[]`, which asserts this in debug builds, but exposes the undefined behavior in release builds. In this patch, I refactored how we enumerate the fields, and gracefully handle the scenario where the field is not found. That case is still bad, but at least it should not expose the undefined behavior in release builds, and should assert earlier in debug builds than before. The motivational case was transformed into a regression test, that would fail if no canonicalization would happen when creating a FieldRegion. This was reduced from a production crash. In the test case, due to how modules work, there would be multiple copies of the same template specialization in the AST. This could lead into inconsistent state when the FieldRegion's Decl was different to the RecordDecl's field - because one referred to the first and the other to the second. This made `calculateOffset` fail to compute the field index, triggering the undefined behavior in production. While this inconsistency gets fixed now, I think the assertion is still warranted to avoid potential undefined behavior in release builds. CPP-6691,CPP-6849 Co-authored-by: Marco Borgeaud <marco.borgeaud@sonarsource.com>
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.