m.ostapenko added a comment. In https://reviews.llvm.org/D16403#992452, @NoQ wrote:
> Thank you, this explanation looks very reasonable. > > All right, so right after the termination of the loop we have > > [B1] > 1: ForStmt (LoopExit) > 2: [B4.5].~A() (Implicit destructor) > 3: [B5.3].~A() (Implicit destructor) > 4: CFGScopeEnd(a) > 5: CFGScopeEnd(b) > > > ... where `[B4.5]` is `A b = a;` and `[B5.3]` is `A a;`. Am i understanding > correctly that while destroying `a` you can still use the storage of `b` > safely? Or should `a` go out of scope before `b` gets destroyed? AFAIU, when we destroying `a` we can still use the storage of `b` because nothing can be allocated into b's storage between calling destructors for `b` and `a`. So, imho the sequence should look like: [B4.5].~A() (Implicit destructor) [B5.3].~A() (Implicit destructor) CFGScopeEnd(b) CFGScopeEnd(a) > Also, is the order of scope ends actually correct here - shouldn't `b` go out > of scope earlier? Given that they are in very different lifetime scopes (`a` > is one for the whole loop, `b` is per-loop-iteration). I guess the order > would matter for the analyzer. Yeah, this is a bug in a current implementation. Will fix this in the next patch version. Repository: rL LLVM https://reviews.llvm.org/D16403 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits