[libc++][NFC] Simplify `optional<T>` and `optional<T&>` a bit (#203665)
- Make `optional<T&>`'s iterator base directly from the storage base
instead of inheriting the empty bases, allowing us to remove the
`is_lvalue_reference_v` conditions in the empty bases
- Move the `__is_constructible_for_optional_{meow}` variables closer to
`make_optional` since that's the only place they're really useful for
now
- Change the SFINAE for the iterator availability to use concepts
instead
The above should make it easier to split up in an upcoming patch.
[llvm-cov] Fix undercounting lines wrapped by gap regions
Lines with no region entry that are wrapped by a gap region were
reported with the gap's count (often 0), even when non-gap segments
on the line indicated the line was actually executed. This caused
llvm-cov to undercount coverage for lines that continue a covered
region after a gap (e.g., closing braces, simple statements following
an if/else).
Check for non-gap segments with HasCount on such lines and use their
max count instead of the gap region's count.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llubi] Add support for exposed provenance (#200596)
This patch implements the semantics of exposed provenance, as described
in [nikic's RFC draft](https://hackmd.io/@nikic/SJBt4mFCll) and
[Miri](https://doc.rust-lang.org/beta/nightly-rustc/miri/enum.Provenance.html).
The provenance of an inttoptr is marked as "wildcard", which picks one
from previously exposed provenances each time a memory access is
performed. For angelic non-determinism, a snapshot of the exposed
provenance set is recorded when inttoptr executes. When a memory access
is performed, all invalid provenances are masked out. If we fail to pick
one, it is UB.
Since all memory objects in llubi are non-overlapping (i.e., there is at
most one memory object satisfying `Obj->inBounds(Addr)` for each
address), we can determine a unique memory object for a wildcard
provenance when the first memory access is performed.
This matches Miri's behavior. Another variant is to resolve the memory
object when inttoptr executes, which gives a limited provenance set
[14 lines not shown]
[llvm-cov] Fix undercounting lines wrapped by gap regions
Lines with no region entry that are wrapped by a gap region were
reported with the gap's count (often 0), even when non-gap segments
on the line indicated the line was actually executed. This caused
llvm-cov to undercount coverage for lines that continue a covered
region after a gap (e.g., closing braces, simple statements following
an if/else).
Check for non-gap segments with HasCount on such lines and use their
max count instead of the gap region's count.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test uses a minimal reproducer: a scoped block with a never-taken
early return followed by a statement. The closing "}" produces a gap
region that wraps to the next line, suppressing its execution count.
The extra statement after the if-block is required — without it,
clang emits a region entry (MinRegionCount > 0) and the bug doesn't
trigger.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test uses a minimal reproducer: a scoped block with a never-taken
early return followed by a statement. The closing "}" produces a gap
region that wraps to the next line, suppressing its execution count.
The extra statement after the if-block is required — without it,
clang emits a region entry (MinRegionCount > 0) and the bug doesn't
trigger.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test uses a minimal reproducer: a scoped block with a never-taken
early return followed by a statement. The closing "}" produces a gap
region that wraps to the next line, suppressing its execution count.
The extra statement after the if-block is required — without it,
clang emits a region entry (MinRegionCount > 0) and the bug doesn't
trigger.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test uses a minimal reproducer: a scoped block with a never-taken
early return followed by a statement. The closing "}" produces a gap
region that wraps to the next line, suppressing its execution count.
The extra statement after the if-block is required — without it,
clang emits a region entry (MinRegionCount > 0) and the bug doesn't
trigger.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test uses a minimal reproducer: a scoped block with a never-taken
early return followed by a statement. The closing "}" produces a gap
region that wraps to the next line, suppressing its execution count.
The extra statement after the if-block is required — without it,
clang emits a region entry (MinRegionCount > 0) and the bug doesn't
trigger.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[SLP]Keep ordered fadd reductions sequential
tryToReduceOrdered vectorizes reductions that are not associative (e.g. an
fadd with reassoc but without nsz). The accumulation order must be
preserved, but the reduction was costed and emitted with reassoc, and the
whole tree was rotated to memory order by reorderTopToBottom, which can
change the result of the sequential reduction.
Drop reassoc from the flags used to cost and emit the reduction so the
generated llvm.vector.reduce.fadd stays ordered, and drop the top-to-bottom
reorder so the reduced values keep their original accumulation order.
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/203741
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test demonstrates this with two scoped blocks containing
never-taken early returns. The statement between them ("int result =
42;") and after them ("return true;") are genuinely executed but
reported with count=0 because the gap region from each block's
closing "}" incorrectly suppresses the line's execution count.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[UBSan] Use EmitCheckedLValue for C++ trivial operator= operands
Further to https://github.com/llvm/llvm-project/pull/190739, use
EmitCheckedLValue for trivial operator= operands
* for the LHS (`lhs->` not handled yet), and
* for the RHS also for function call syntax.
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports lines as uncovered when a gap
region with count=0 wraps into a line that has non-entry segments
with count > 0.
The test demonstrates this with two scoped blocks containing
never-taken early returns. The statement between them ("int result =
42;") and after them ("return true;") are genuinely executed but
reported with count=0 because the gap region from each block's
closing "}" incorrectly suppresses the line's execution count.
Test inputs generated with Apple system clang which produces this
specific segment pattern. Upstream clang does not produce gap regions
in this context.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports a line as uncovered when the
wrapping segment has count=0 and the line has no region entries, even
if it has non-entry segments with count > 0.
This test uses coverage data from Apple clang which produces the
specific segment pattern that triggers this: a closing brace "}" after
a never-taken if-block, where the non-gap segment returning to the
parent function's count is ignored.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[CoverageMapping] Fix LineCoverageStats incorrectly using gap region count
When a line's wrapping segment is a gap region with count=0, but the
line has non-gap segments with count > 0 (not region entries),
LineCoverageStats incorrectly reports the line as uncovered.
This happens when a zero-count gap region (e.g., from a never-taken
if-branch closing brace) extends past subsequent covered lines. The
fix checks non-gap HasCount segments on the line when MinRegionCount
is 0, using their max count instead of the gap's count.
Also skip initializing ExecutionCount from a gap wrapping segment,
since gap regions should not contribute to the line's execution count.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[NFC][tests] Rename test file and function names to reflect scope/content (#203731)
Rename test file to reflect scope (includes array bounds checking).
Rename test functions for internal convention consistency:
Consistently use "deref" and "subscript" to refer to `*p` and `arr[idx]`
expression forms.
[CoverageMapping] Fix LineCoverageStats incorrectly using gap region count
When a line's wrapping segment is a gap region with count=0, but the
line has non-gap segments with count > 0 (not region entries),
LineCoverageStats incorrectly reports the line as uncovered.
This happens when a zero-count region (e.g., from a never-taken
if-branch) extends past subsequent covered lines via a gap segment.
The fix:
1. Skip initializing ExecutionCount from gap wrapping segments
2. When MinRegionCount is 0, check non-gap HasCount segments on the
line and use their max count
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add failing test for gap region line coverage bug
LineCoverageStats incorrectly reports a line as uncovered when the
wrapping segment has count=0 and the line has no region entries, even
if it has non-entry segments with count > 0.
This test uses coverage data from Apple clang which produces the
specific segment pattern that triggers this: a closing brace "}" after
a never-taken if-block, where the non-gap segment returning to the
parent function's count is ignored.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[NFC] Rename test functions for internal convention consistency
Consistently use "deref" and "subscript" to refer to `*p` and `arr[idx]`
expression forms.
[CoverageMapping] Fix LineCoverageStats incorrectly using gap region count
When a line's wrapping segment is a gap region with count=0, but the
line has non-gap segments with count > 0 (not region entries),
LineCoverageStats incorrectly reports the line as uncovered.
This happens when a zero-count gap region (e.g., from a never-taken
if-branch closing brace) extends past subsequent covered lines. The
fix checks non-gap HasCount segments on the line when MinRegionCount
is 0, using their max count instead of the gap's count.
Also skip initializing ExecutionCount from a gap wrapping segment,
since gap regions should not contribute to the line's execution count.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply at anthropic.com>
[llvm-cov] Add inline exclusion marker support for coverage reporting
Add --exclude-line-regex, --exclude-region-start-regex, and
--exclude-region-stop-regex options to llvm-cov. These allow excluding
lines from coverage totals based on inline source comments.
Defaults: LCOV_EXCL_LINE (single line), LCOV_EXCL_START/LCOV_EXCL_STOP
(region). This brings parity with lcov/gcov's exclusion markers and
kcov's --exclude-line regex support.
The implementation scans source files for markers when loaded, builds a
per-file set of excluded line numbers, and consistently applies
exclusions across all output formats:
- Line coverage totals (subtracted in prepareFileReports)
- Region coverage totals (regions starting on excluded lines)
- Function coverage totals (functions starting on excluded lines)
- "show" text output (no count column, no red highlighting)
- "show" HTML output (skipped-line class instead of uncovered-line)
- JSON export segments (filtered out)
[6 lines not shown]
[llvm-cov] Add inline exclusion marker support for coverage reporting
Add --exclude-line-regex, --exclude-region-start-regex, and
--exclude-region-stop-regex options to llvm-cov. These allow excluding
lines from coverage totals based on inline source comments.
Defaults: LCOV_EXCL_LINE (single line), LCOV_EXCL_START/LCOV_EXCL_STOP
(region). This brings parity with lcov/gcov's exclusion markers and
kcov's --exclude-line regex support.
The implementation scans source files for markers when loaded, builds a
per-file set of excluded line numbers, and consistently applies
exclusions across all output formats:
- Line coverage totals (subtracted in prepareFileReports)
- Region coverage totals (regions starting on excluded lines)
- Function coverage totals (functions starting on excluded lines)
- "show" text output (no count column, no red highlighting)
- "show" HTML output (skipped-line class instead of uncovered-line)
- JSON export segments (filtered out)
[6 lines not shown]
