Fix owned iterator arrow false positives

[KiritoYG]

Default-constructed iterators that return &ownedMember from operator-> can be used to initialize their storage, but the complete example in Trac #6572, comment 7 currently produces eraseDereference, uninitvar, and uninitStructMember. This change makes that complete example diagnostic-free.

The iterator check recognizes an initial arrow access whose visible implementations directly return owned storage. Iterator classification, unary dereference checking, and post-erase invalidation remain intact. Unknown bodies, inherited/proxy arrows and overloaded address-of stay conservative.

The initialization analysis additionally recognizes standalone writes through a narrowly proven accessor: a local receiver has one plain owned member with one primitive scalar, and every arrow overload returns the same member's built-in address. This lets the existing flow distinguish initialization from read-modify-write without a generic non-const-call bailout. Nested expression writes, alias bindings, complex layouts and writes to captured outer objects in deferred lambdas retain existing handling.

Validation:

• Native regressions reproduce the original diagnostics on unchanged production and pass after the fixes.
• Windows Clang 22.1.8: 5,303 native tests pass, with 351 existing TODO assertions.
• Independent Linux GCC 11.4.0 verification, with warnings treated as errors: 5,365 native tests pass (360 existing TODO assertions), plus 199 focused initialization/STL tests. The helper differs from this source only by its isolated verification workflow.
• 71 syntax-valid CLI fixtures cover the original example, true reads, conditional writes, overload/layout boundaries and deferred execution; 55 explicit clean/detection assertions pass, with 16 unsupported or pre-existing cases recorded separately.
• Uncrustify 0.80.1, git diff --check, and a file-scoped equivalent of the project's self-check pass.

Please assign this work to KiritoYG if needed and consider it under the published $10 bounty schedule. Please confirm eligibility and the supported payment route after acceptance and the required ticket closure. GitHub Sponsors is available if supported. No award or payment is being claimed.

[danmar]

This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.

I am worried that the uninitvar part is tailored to the exact example in the ticket. I built the PR and tried small variations of it:

struct P2 { int m_place; int m_other; };
struct It2 { P2 m_ptr; P2* operator->() { return &m_ptr; } };
It2 f2() { It2 it; it->m_place = 0; it->m_other = 0; return it; }   // still uninitvar + uninitStructMember

struct P3 { int m_place; };
struct It3 { P3 m_ptr; int m_extra; P3* operator->() { return &m_ptr; } };
It3 f3() { It3 it; it->m_place = 0; it.m_extra = 0; return it; }    // still uninitvar + uninitStructMember

Only the variant with exactly one member in both the iterator and the pointee is fixed. That adds about 80 lines of very specific shape matching to astutils, plus hooks in ValueFlowAnalyzer::analyzeMatch(), MemberExpressionAnalyzer and two places in checkuninitvar. That is a lot of special-casing in core code for one layout.

Maybe split the PR? The checkstl eraseDereference part is self-contained. For the uninit part, a more general approach could map it->x to it.m_ptr.x when operator-> is known to return &m_ptr, so the existing member tracking handles any layout. Alternatively, treat a call to a non-const user operator-> on an uninitialized object like other non-const member calls.

[danmar]

This is an AI review. Take it with a grain of salt and feel free to reject it by resolving the comment.

Performance: this loops over the whole symdb.scopeList every time getSingleMemberArrowWriteTarget() gets this far. The function is called from ValueFlowAnalyzer::analyzeMatch(), from MemberExpressionAnalyzer::match() and twice from checkuninitvar, so the scan can repeat many times per file. If this is kept, maybe compute "has any operator&" once (checkstl.cpp in this PR already does a similar scan once per iterators() call).