[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
steveire abandoned this revision. steveire added a comment. An alternative was written and committed. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56959/new/ https://reviews.llvm.org/D56959 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
riccibruno added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
riccibruno wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > steveire wrote:
> > > > > aaron.ballman wrote:
> > > > > > Rather than gin these objects up on demand every time they're
> > > > > > needed, I'd prefer to see the class store `Association` objects
> > > > > > directly. I don't think it will be easy to do that and still
> > > > > > support `getAssocExprs()` and `getAssocTypeSourceInfos()`, so I
> > > > > > think those APIs should be removed in favor of this one. There's
> > > > > > currently not many uses of `getAssocExprs()` or
> > > > > > `getAssocTypeSourceInfos()` (I spot one each in Clang) so migration
> > > > > > to the new API should not be onerous.
> > > > > >
> > > > > > This should also have a range-based accessor version so that users
> > > > > > aren't required to use iterative loops to access the information (a
> > > > > > lot of the places you're already touching could use that
> > > > > > range-based interface).
> > > > > I would prefer that too, but it doesn't seem to be possible. This is
> > > > > a sub-range of the `SubExprs` returned from `children()`.
> > > > >
> > > > > In theory, that could be split into two members, but then you would
> > > > > need a range library to recombine them and implement `children()`:
> > > > > https://godbolt.org/z/ZVamdC
> > > > >
> > > > > This seems to be the best approach for now, and AFAIK it excludes a
> > > > > range-accessor.
> > > > > I would prefer that too, but it doesn't seem to be possible. This is
> > > > > a sub-range of the SubExprs returned from children().
> > > >
> > > > Ugh, you're right. :-(
> > > >
> > > > > In theory, that could be split into two members, but then you would
> > > > > need a range library to recombine them and implement children():
> > > > > https://godbolt.org/z/ZVamdC
> > > >
> > > > We have zip iterators that could be used to implement this, I believe.
> > > > (see STLExtras.h)
> > > >
> > > > Alternatively, we could tail-allocate the Association objects with
> > > > (perhaps references to) pointers back into the Expr tail-allocated
> > > > array. Not ideal, but does provide a clean interface.
> > > >
> > > > @riccibruno may have other ideas on how to pack the arrays, as he's
> > > > done a lot of this work recently.
> > > > We have zip iterators that could be used to implement this, I believe.
> > >
> > > You're right, there is a `concat` there, but on second thought - because
> > > Association and Stmt don't share a base, I don't think it can work.
> > >
> > > > Alternatively, we could tail-allocate the Association objects with
> > > > (perhaps references to) pointers back into the Expr tail-allocated
> > > > array. Not ideal, but does provide a clean interface.
> > >
> > > Perhaps this can work, but I don't know how to do it. If you have scope
> > > for it in your part of the efforts, it would be a good way to get this
> > > unblocked.
> > > Perhaps this can work, but I don't know how to do it. If you have scope
> > > for it in your part of the efforts, it would be a good way to get this
> > > unblocked.
> >
> > I'll put some time into it today and see where it goes. You may be right
> > that this is more work than it's worth, so we'll see.
> I don't see what would prevent tail-allocating the array of sub-expression
> and the array of `TypeSourceInfo`, and removing the `getAssocExpr`,
> `getAssocTypeSourceInfo`, `getAssocType` interface in favor of a single
> `getAssociation`. Then create a range version of `getAssociation` using the
> fact that if you know where you are in the sub-expression array, you know
> where is the corresponding `TypeSourceInfo`. To know which index correspond
> to the selected sub-expression you could use one of the low bits in the
> `TypeSourceInfo` pointers.
>
> This means that `children` is still simple to implement, and users can use a
> single unified
> interface via `getAssociation` and the range version `associations()`. From
> the point of view of the users it would be like if the `Association` objects
> were stored contiguously.
Made a patch which roughly the above idea: D57098
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
riccibruno added a comment.
Some small additional remarks if you are already modifying this class.
Comment at: include/clang/AST/Expr.h:5021
unsigned NumAssocs, ResultIndex;
SourceLocation GenericLoc, DefaultLoc, RParenLoc;
It is possible to stuff one `SourceLocation` in the bit-fields of `Stmt` to
save one more pointer.
Comment at: include/clang/AST/Expr.h:5113
SourceLocation getBeginLoc() const LLVM_READONLY { return GenericLoc; }
SourceLocation getEndLoc() const LLVM_READONLY { return RParenLoc; }
I believe these `LLVM_READONLY` are pointless here.
Comment at: include/clang/AST/Expr.h:5125
}
friend class ASTStmtReader;
};
Move this friend decl to the top ?
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
riccibruno added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > steveire wrote:
> > > > aaron.ballman wrote:
> > > > > Rather than gin these objects up on demand every time they're needed,
> > > > > I'd prefer to see the class store `Association` objects directly. I
> > > > > don't think it will be easy to do that and still support
> > > > > `getAssocExprs()` and `getAssocTypeSourceInfos()`, so I think those
> > > > > APIs should be removed in favor of this one. There's currently not
> > > > > many uses of `getAssocExprs()` or `getAssocTypeSourceInfos()` (I spot
> > > > > one each in Clang) so migration to the new API should not be onerous.
> > > > >
> > > > > This should also have a range-based accessor version so that users
> > > > > aren't required to use iterative loops to access the information (a
> > > > > lot of the places you're already touching could use that range-based
> > > > > interface).
> > > > I would prefer that too, but it doesn't seem to be possible. This is a
> > > > sub-range of the `SubExprs` returned from `children()`.
> > > >
> > > > In theory, that could be split into two members, but then you would
> > > > need a range library to recombine them and implement `children()`:
> > > > https://godbolt.org/z/ZVamdC
> > > >
> > > > This seems to be the best approach for now, and AFAIK it excludes a
> > > > range-accessor.
> > > > I would prefer that too, but it doesn't seem to be possible. This is a
> > > > sub-range of the SubExprs returned from children().
> > >
> > > Ugh, you're right. :-(
> > >
> > > > In theory, that could be split into two members, but then you would
> > > > need a range library to recombine them and implement children():
> > > > https://godbolt.org/z/ZVamdC
> > >
> > > We have zip iterators that could be used to implement this, I believe.
> > > (see STLExtras.h)
> > >
> > > Alternatively, we could tail-allocate the Association objects with
> > > (perhaps references to) pointers back into the Expr tail-allocated array.
> > > Not ideal, but does provide a clean interface.
> > >
> > > @riccibruno may have other ideas on how to pack the arrays, as he's done
> > > a lot of this work recently.
> > > We have zip iterators that could be used to implement this, I believe.
> >
> > You're right, there is a `concat` there, but on second thought - because
> > Association and Stmt don't share a base, I don't think it can work.
> >
> > > Alternatively, we could tail-allocate the Association objects with
> > > (perhaps references to) pointers back into the Expr tail-allocated array.
> > > Not ideal, but does provide a clean interface.
> >
> > Perhaps this can work, but I don't know how to do it. If you have scope for
> > it in your part of the efforts, it would be a good way to get this
> > unblocked.
> > Perhaps this can work, but I don't know how to do it. If you have scope for
> > it in your part of the efforts, it would be a good way to get this
> > unblocked.
>
> I'll put some time into it today and see where it goes. You may be right that
> this is more work than it's worth, so we'll see.
I don't see what would prevent tail-allocating the array of sub-expression and
the array of `TypeSourceInfo`, and removing the `getAssocExpr`,
`getAssocTypeSourceInfo`, `getAssocType` interface in favor of a single
`getAssociation`. Then create a range version of `getAssociation` using the
fact that if you know where you are in the sub-expression array, you know where
is the corresponding `TypeSourceInfo`. To know which index correspond to the
selected sub-expression you could use one of the low bits in the
`TypeSourceInfo` pointers.
This means that `children` is still simple to implement, and users can use a
single unified
interface via `getAssociation` and the range version `associations()`. From the
point of view of the users it would be like if the `Association` objects were
stored contiguously.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
aaron.ballman added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
steveire wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > Rather than gin these objects up on demand every time they're needed,
> > > > I'd prefer to see the class store `Association` objects directly. I
> > > > don't think it will be easy to do that and still support
> > > > `getAssocExprs()` and `getAssocTypeSourceInfos()`, so I think those
> > > > APIs should be removed in favor of this one. There's currently not many
> > > > uses of `getAssocExprs()` or `getAssocTypeSourceInfos()` (I spot one
> > > > each in Clang) so migration to the new API should not be onerous.
> > > >
> > > > This should also have a range-based accessor version so that users
> > > > aren't required to use iterative loops to access the information (a lot
> > > > of the places you're already touching could use that range-based
> > > > interface).
> > > I would prefer that too, but it doesn't seem to be possible. This is a
> > > sub-range of the `SubExprs` returned from `children()`.
> > >
> > > In theory, that could be split into two members, but then you would need
> > > a range library to recombine them and implement `children()`:
> > > https://godbolt.org/z/ZVamdC
> > >
> > > This seems to be the best approach for now, and AFAIK it excludes a
> > > range-accessor.
> > > I would prefer that too, but it doesn't seem to be possible. This is a
> > > sub-range of the SubExprs returned from children().
> >
> > Ugh, you're right. :-(
> >
> > > In theory, that could be split into two members, but then you would need
> > > a range library to recombine them and implement children():
> > > https://godbolt.org/z/ZVamdC
> >
> > We have zip iterators that could be used to implement this, I believe. (see
> > STLExtras.h)
> >
> > Alternatively, we could tail-allocate the Association objects with (perhaps
> > references to) pointers back into the Expr tail-allocated array. Not ideal,
> > but does provide a clean interface.
> >
> > @riccibruno may have other ideas on how to pack the arrays, as he's done a
> > lot of this work recently.
> > We have zip iterators that could be used to implement this, I believe.
>
> You're right, there is a `concat` there, but on second thought - because
> Association and Stmt don't share a base, I don't think it can work.
>
> > Alternatively, we could tail-allocate the Association objects with (perhaps
> > references to) pointers back into the Expr tail-allocated array. Not ideal,
> > but does provide a clean interface.
>
> Perhaps this can work, but I don't know how to do it. If you have scope for
> it in your part of the efforts, it would be a good way to get this unblocked.
> Perhaps this can work, but I don't know how to do it. If you have scope for
> it in your part of the efforts, it would be a good way to get this unblocked.
I'll put some time into it today and see where it goes. You may be right that
this is more work than it's worth, so we'll see.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
steveire marked an inline comment as done.
steveire added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > Rather than gin these objects up on demand every time they're needed, I'd
> > > prefer to see the class store `Association` objects directly. I don't
> > > think it will be easy to do that and still support `getAssocExprs()` and
> > > `getAssocTypeSourceInfos()`, so I think those APIs should be removed in
> > > favor of this one. There's currently not many uses of `getAssocExprs()`
> > > or `getAssocTypeSourceInfos()` (I spot one each in Clang) so migration to
> > > the new API should not be onerous.
> > >
> > > This should also have a range-based accessor version so that users aren't
> > > required to use iterative loops to access the information (a lot of the
> > > places you're already touching could use that range-based interface).
> > I would prefer that too, but it doesn't seem to be possible. This is a
> > sub-range of the `SubExprs` returned from `children()`.
> >
> > In theory, that could be split into two members, but then you would need a
> > range library to recombine them and implement `children()`:
> > https://godbolt.org/z/ZVamdC
> >
> > This seems to be the best approach for now, and AFAIK it excludes a
> > range-accessor.
> > I would prefer that too, but it doesn't seem to be possible. This is a
> > sub-range of the SubExprs returned from children().
>
> Ugh, you're right. :-(
>
> > In theory, that could be split into two members, but then you would need a
> > range library to recombine them and implement children():
> > https://godbolt.org/z/ZVamdC
>
> We have zip iterators that could be used to implement this, I believe. (see
> STLExtras.h)
>
> Alternatively, we could tail-allocate the Association objects with (perhaps
> references to) pointers back into the Expr tail-allocated array. Not ideal,
> but does provide a clean interface.
>
> @riccibruno may have other ideas on how to pack the arrays, as he's done a
> lot of this work recently.
> We have zip iterators that could be used to implement this, I believe.
You're right, there is a `concat` there, but on second thought - because
Association and Stmt don't share a base, I don't think it can work.
> Alternatively, we could tail-allocate the Association objects with (perhaps
> references to) pointers back into the Expr tail-allocated array. Not ideal,
> but does provide a clean interface.
Perhaps this can work, but I don't know how to do it. If you have scope for it
in your part of the efforts, it would be a good way to get this unblocked.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
aaron.ballman added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
steveire wrote:
> aaron.ballman wrote:
> > Rather than gin these objects up on demand every time they're needed, I'd
> > prefer to see the class store `Association` objects directly. I don't think
> > it will be easy to do that and still support `getAssocExprs()` and
> > `getAssocTypeSourceInfos()`, so I think those APIs should be removed in
> > favor of this one. There's currently not many uses of `getAssocExprs()` or
> > `getAssocTypeSourceInfos()` (I spot one each in Clang) so migration to the
> > new API should not be onerous.
> >
> > This should also have a range-based accessor version so that users aren't
> > required to use iterative loops to access the information (a lot of the
> > places you're already touching could use that range-based interface).
> I would prefer that too, but it doesn't seem to be possible. This is a
> sub-range of the `SubExprs` returned from `children()`.
>
> In theory, that could be split into two members, but then you would need a
> range library to recombine them and implement `children()`:
> https://godbolt.org/z/ZVamdC
>
> This seems to be the best approach for now, and AFAIK it excludes a
> range-accessor.
> I would prefer that too, but it doesn't seem to be possible. This is a
> sub-range of the SubExprs returned from children().
Ugh, you're right. :-(
> In theory, that could be split into two members, but then you would need a
> range library to recombine them and implement children():
> https://godbolt.org/z/ZVamdC
We have zip iterators that could be used to implement this, I believe. (see
STLExtras.h)
Alternatively, we could tail-allocate the Association objects with (perhaps
references to) pointers back into the Expr tail-allocated array. Not ideal, but
does provide a clean interface.
@riccibruno may have other ideas on how to pack the arrays, as he's done a lot
of this work recently.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
steveire marked 2 inline comments as done.
steveire added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
aaron.ballman wrote:
> Rather than gin these objects up on demand every time they're needed, I'd
> prefer to see the class store `Association` objects directly. I don't think
> it will be easy to do that and still support `getAssocExprs()` and
> `getAssocTypeSourceInfos()`, so I think those APIs should be removed in favor
> of this one. There's currently not many uses of `getAssocExprs()` or
> `getAssocTypeSourceInfos()` (I spot one each in Clang) so migration to the
> new API should not be onerous.
>
> This should also have a range-based accessor version so that users aren't
> required to use iterative loops to access the information (a lot of the
> places you're already touching could use that range-based interface).
I would prefer that too, but it doesn't seem to be possible. This is a
sub-range of the `SubExprs` returned from `children()`.
In theory, that could be split into two members, but then you would need a
range library to recombine them and implement `children()`:
https://godbolt.org/z/ZVamdC
This seems to be the best approach for now, and AFAIK it excludes a
range-accessor.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
aaron.ballman added inline comments.
Comment at: include/clang/AST/Expr.h:5068
+ Association getAssociation(unsigned I) const {
+return Association(cast(SubExprs[END_EXPR + I]), AssocTypes[I],
Rather than gin these objects up on demand every time they're needed, I'd
prefer to see the class store `Association` objects directly. I don't think it
will be easy to do that and still support `getAssocExprs()` and
`getAssocTypeSourceInfos()`, so I think those APIs should be removed in favor
of this one. There's currently not many uses of `getAssocExprs()` or
`getAssocTypeSourceInfos()` (I spot one each in Clang) so migration to the new
API should not be onerous.
This should also have a range-based accessor version so that users aren't
required to use iterative loops to access the information (a lot of the places
you're already touching could use that range-based interface).
Comment at: lib/AST/ASTDumper.cpp:1467
dumpChild([=] {
- if (const TypeSourceInfo *TSI = E->getAssocTypeSourceInfo(I)) {
+ const auto Assoc = E->getAssociation(I);
+ const TypeSourceInfo *TSI = Assoc.getTypeSourceInfo();
Don't use `auto` here.
Comment at: lib/AST/StmtPrinter.cpp:1266
OS << ", ";
-QualType T = Node->getAssocType(i);
+auto Assoc = Node->getAssociation(i);
+QualType T = Assoc.getType();
Don't use `auto`.
Comment at: lib/AST/StmtProfile.cpp:1263
for (unsigned i = 0; i != S->getNumAssocs(); ++i) {
-QualType T = S->getAssocType(i);
+auto Assoc = S->getAssociation(i);
+QualType T = Assoc.getType();
Or here (or anywhere similar in this patch; I'll stop commenting on them).
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56959/new/
https://reviews.llvm.org/D56959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
riccibruno added inline comments. Comment at: include/clang/AST/Expr.h:5020 Stmt **SubExprs; unsigned NumAssocs, ResultIndex; SourceLocation GenericLoc, DefaultLoc, RParenLoc; I know that this is not part of this patch, but these arrays are begging to be tail-allocated if you want to have a go at it. Comment at: include/clang/AST/Expr.h:5047 +bool Selected; + + public: What about some comments ? I can guess but it is better to have too much doc than not enough imho. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56959/new/ https://reviews.llvm.org/D56959 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D56959: [AST] NFC: Introduce new class GenericSelectionExpr::Association
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.
As a type, this can be visited upon. This is similar in spirit to the
BlockDecl::Capture type.
Repository:
rC Clang
https://reviews.llvm.org/D56959
Files:
include/clang/AST/Expr.h
include/clang/AST/RecursiveASTVisitor.h
include/clang/AST/StmtDataCollectors.td
lib/AST/ASTDumper.cpp
lib/AST/StmtPrinter.cpp
lib/AST/StmtProfile.cpp
lib/Sema/SemaExprObjC.cpp
lib/Sema/SemaPseudoObject.cpp
lib/Sema/TreeTransform.h
lib/Serialization/ASTWriterStmt.cpp
Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -972,8 +972,9 @@
Record.AddStmt(E->getControllingExpr());
for (unsigned I = 0, N = E->getNumAssocs(); I != N; ++I) {
-Record.AddTypeSourceInfo(E->getAssocTypeSourceInfo(I));
-Record.AddStmt(E->getAssocExpr(I));
+auto Assoc = E->getAssociation(I);
+Record.AddTypeSourceInfo(Assoc.getTypeSourceInfo());
+Record.AddStmt(Assoc.getExpr());
}
Record.push_back(E->isResultDependent() ? -1U : E->getResultIndex());
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -9072,7 +9072,8 @@
SmallVector AssocExprs;
SmallVector AssocTypes;
for (unsigned i = 0; i != E->getNumAssocs(); ++i) {
-TypeSourceInfo *TS = E->getAssocTypeSourceInfo(i);
+auto Assoc = E->getAssociation(i);
+TypeSourceInfo *TS = Assoc.getTypeSourceInfo();
if (TS) {
TypeSourceInfo *AssocType = getDerived().TransformType(TS);
if (!AssocType)
@@ -9082,7 +9083,7 @@
AssocTypes.push_back(nullptr);
}
-ExprResult AssocExpr = getDerived().TransformExpr(E->getAssocExpr(i));
+ExprResult AssocExpr = getDerived().TransformExpr(Assoc.getExpr());
if (AssocExpr.isInvalid())
return ExprError();
AssocExprs.push_back(AssocExpr.get());
Index: lib/Sema/SemaPseudoObject.cpp
===
--- lib/Sema/SemaPseudoObject.cpp
+++ lib/Sema/SemaPseudoObject.cpp
@@ -144,10 +144,11 @@
SmallVector assocTypes(numAssocs);
for (unsigned i = 0; i != numAssocs; ++i) {
- Expr *assoc = gse->getAssocExpr(i);
+ auto A = gse->getAssociation(i);
+ Expr *assoc = A.getExpr();
if (i == resultIndex) assoc = rebuild(assoc);
assocs[i] = assoc;
- assocTypes[i] = gse->getAssocTypeSourceInfo(i);
+ assocTypes[i] = A.getTypeSourceInfo();
}
return new (S.Context) GenericSelectionExpr(S.Context,
Index: lib/Sema/SemaExprObjC.cpp
===
--- lib/Sema/SemaExprObjC.cpp
+++ lib/Sema/SemaExprObjC.cpp
@@ -4335,8 +4335,9 @@
SmallVector subExprs(n);
SmallVector subTypes(n);
for (unsigned i = 0; i != n; ++i) {
- subTypes[i] = gse->getAssocTypeSourceInfo(i);
- Expr *sub = gse->getAssocExpr(i);
+ auto Assoc = gse->getAssociation(i);
+ subTypes[i] = Assoc.getTypeSourceInfo();
+ Expr *sub = Assoc.getExpr();
if (i == gse->getResultIndex())
sub = stripARCUnbridgedCast(sub);
subExprs[i] = sub;
Index: lib/AST/StmtProfile.cpp
===
--- lib/AST/StmtProfile.cpp
+++ lib/AST/StmtProfile.cpp
@@ -1260,12 +1260,13 @@
void StmtProfiler::VisitGenericSelectionExpr(const GenericSelectionExpr *S) {
VisitExpr(S);
for (unsigned i = 0; i != S->getNumAssocs(); ++i) {
-QualType T = S->getAssocType(i);
+auto Assoc = S->getAssociation(i);
+QualType T = Assoc.getType();
if (T.isNull())
ID.AddPointer(nullptr);
else
VisitType(T);
-VisitExpr(S->getAssocExpr(i));
+VisitExpr(Assoc.getExpr());
}
}
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1263,13 +1263,14 @@
PrintExpr(Node->getControllingExpr());
for (unsigned i = 0; i != Node->getNumAssocs(); ++i) {
OS << ", ";
-QualType T = Node->getAssocType(i);
+auto Assoc = Node->getAssociation(i);
+QualType T = Assoc.getType();
if (T.isNull())
OS << "default";
else
T.print(OS, Policy);
OS << ": ";
-PrintExpr(Node->getAssocExpr(i));
+PrintExpr(Assoc.getExpr());
}
OS << ")";
}
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -1464,19 +1464,21 @@
for (unsigned I = 0, N = E->getNumAssocs(); I != N; ++I) {
dumpChild([=] {
- if (const TypeSourceInfo *TSI = E->getAssocTypeSourceInfo(I)) {
+ const auto Assoc = E->getAssociation(I);
+
