[PATCH] D139544: [clang][dataflow] Add support for structured bindings of tuple-like types.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

Thanks for clarifying the issues here.  A few thoughts:

1. Thanks for clarifying about the blank lines. I was wondering how to read that and I think that fills in an important missing detail for me.

2. I'm particularly interested in the case of tuple-like containers, which is a little different (though I think the same point holds):

Example: https://godbolt.org/z/qcWMdG33T

  #include <tuple>
  std::tuple<bool, int> mk();
  
  void f() {
    auto [b, i] = mk();
    (void)i;
  }

CFG:

  void f()
   [B2 (ENTRY)]
     Succs (1): B1
  
   [B1]
     1: mk
     2: [B1.1] (ImplicitCastExpr, FunctionToPointerDecay, std::tuple<_Bool, int> (*)(void))
     3: [B1.2]() (CXXRecordTypedCall, [B1.4])
     4: auto = mk();
     5: get<0UL>
     6: [B1.5] (ImplicitCastExpr, FunctionToPointerDecay, typename tuple_element<0UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) noexcept)
     7: 
     8: [B1.7] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
     9: [B1.6]([B1.8])
    10: std::tuple_element<0, std::tuple<bool, int>>::type b = get<0UL>();
    11: get<1UL>
    12: [B1.11] (ImplicitCastExpr, FunctionToPointerDecay, typename tuple_element<1UL, tuple<_Bool, int> >::type &&(*)(tuple<_Bool, int> &&) noexcept)
    13: 
    14: [B1.13] (ImplicitCastExpr, NoOp, std::tuple<_Bool, int>)
    15: [B1.12]([B1.14])
    16: std::tuple_element<1, std::tuple<bool, int>>::type i = get<1UL>();
    17: i
    18: (void)[B1.17] (CStyleCastExpr, ToVoid, void)
     Preds (1): B2
     Succs (1): B0
  
   [B0 (EXIT)]
     Preds (1): B1

Here, both lines 7 and 13 are blank but seem to be the underlying tuple that's being deconstructed.  Are these different instances of the DecompositionDecl or are they (unprinted) references back to line 4?

3. I'm still bothered that this seems to violate the design/philosophy of the CFG, which I take as ensuring that elements proceed in the order of operation. I see the problem here -- that the AST includes backedge, but can we solve it by adding another synthesized element for the object being deconstructed? Or, perhaps we could add new CFG kind that marks the appearance of the DecompositionDecl an extra time? That is, first time is so that the DecompositionDecl can be referenced as it is now, but second time is so that the statement can be evaluated in the proper order (after all of its constituent elements)?

Finally, a nit: why doesn't line 13 in your example, and lines 7 and 13 in my example, print? Is that something that I could add to the CFG printer?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139544/new/

https://reviews.llvm.org/D139544