Implement is_structured_binding metafunction

[BaLiKfromUA]

Implements #44

Describe your changes

Added implementation of is_structured_binding + adapted implementation of type_of and extract functions

Testing performed

Added tests for my changes to entity-classification.pass.cpp

 env LIT_FILTER=entity-classification.pass.cpp ninja check-cxx -C build-llvm/
....
Testing Time: 1.17s

Total Discovered Tests: 9692
  Excluded: 9691 (99.99%)
  Passed  :    1 (0.01%)

[BaLiKfromUA]

I created this PR to receive feedback about my current progress while I am dealing with new implementation of #11 .

I tried to cover 3 main cases mentioned in the issue but will come back and add more tests later.

Plus, need to investigate needs for changes of related functions -- type_of, extract

[BaLiKfromUA]

Decided to go this way because of documentation:

  /// Get the variable (if any) that holds the value of evaluating the binding.
  /// Only present for user-defined bindings for tuple-like types.
  VarDecl *getHoldingVar() const;

[katzdm]

Upon more careful reading of the Standard, I think I led you astray - we should not return true for is_variable in any of these cases.

I realized this while attempting to verify that getHoldingVar was the right API for this task, during which I came upon this code which implements tuple-like binding decomposition in clang. The synthesized variable RefVD corresponds to the variable

    S U_i r_i = initializer ;

mandated by [dcl.struct.bind]/4, but notice that it's never stored as a property of the BindingDecl B that's being constructed. Instead, the Sema::BuildDeclarationNameExpr() function is used to synthesize an expression referencing the variable, and that expression is set as the "binding" via B->setBinding(E).

Looking back at the Standard, this lines up:

Each v_i is the name of an lvalue of type T_i that refers to the object bound to r_i; the referenced type is T_i.

So even though a variable is synthesized for each binding in a tuple-like decomposition, I believe the binding itself is still not a variable, but rather a named expression referencing the synthesized variable.

Sorry for the mixup!

[BaLiKfromUA]

Thanks for deep dive! I reverted changes to implementation but left existing tests

[katzdm]

Upon more careful reading of the Standard, I think I led you astray - we should not return true for is_variable in any of these cases.

I realized this while attempting to verify that getHoldingVar was the right API for this task, during which I came upon this code which implements tuple-like binding decomposition in clang. The synthesized variable RefVD corresponds to the variable

    S U_i r_i = initializer ;

mandated by [dcl.struct.bind]/4, but notice that it's never stored as a property of the BindingDecl B that's being constructed. Instead, the Sema::BuildDeclarationNameExpr() function is used to synthesize an expression referencing the variable, and that expression is set as the "binding" via B->setBinding(E).

Looking back at the Standard, this lines up:

Each v_i is the name of an lvalue of type T_i that refers to the object bound to r_i; the referenced type is T_i.

So even though a variable is synthesized for each binding in a tuple-like decomposition, I believe the binding itself is still not a variable, but rather a named expression referencing the synthesized variable.

Sorry for the mixup!

[BaLiKfromUA]

Thanks for the initial review! I will work on testing and adapting type_of and extract implementations.

So far, at least type_of implementation is definetely needs few small changes.

After my test&fixes, I'll request your review again + meanwhile will investigate which implemented functions might need some changes

[BaLiKfromUA]

I think I am ready for next iteration of review. I slightly changed implementations of type_of and extract functions.

One remark about my changes: I am not sure about my changes to extract function because I didn't come up with all relevant test cases. My current tests are inspired by tests from to-and-from-values.pass.cpp.

constexpr auto p = std::pair{1, 2};
auto& [x4, y4] = p;

static_assert(extract<int>(^x4) == x4);
static_assert(extract<int&>(^x4) == x4);
static_assert(&extract<int&>(^x4) == &x4);

static_assert(extract<int>(^y4) == y4);
static_assert(extract<int&>(^y4) == y4);
static_assert(&extract<int&>(^y4) == &y4);

[katzdm]

I think I am ready for next iteration of review. I slightly changed implementations of type_of and extract functions.

One remark about my changes: I am not sure about my changes to extract function because I didn't come up with all relevant test cases. My current tests are inspired by tests from to-and-from-values.pass.cpp.

constexpr auto p = std::pair{1, 2};
auto& [x4, y4] = p;

static_assert(extract<int>(^x4) == x4);
static_assert(extract<int&>(^x4) == x4);
static_assert(&extract<int&>(^x4) == &x4);

static_assert(extract<int>(^y4) == y4);
static_assert(extract<int&>(^y4) == y4);
static_assert(&extract<int&>(^y4) == &y4);

Valentyn, I think these look great! Note that it hasn't been decided yet whether to support extract or type_of on structured bindings for P2996 (though the current wording for type_of seems like it would support it). Let's keep this for now though. Your changes will be on public godbolt tomorrow, so please feel free to poke and prod the APIs; let me know if anything looks wrong or crashes.

Thanks so much for the contribution!!