Guard against a null pointer dereference that caused Clang to crash
when processing a class containing an _Atomic(<typ>) data member,
and that is tagged with 'dllexport'.
Details
Diff Detail
Event Timeline
When a class that has been tagged as dllexport (for an MSVC target) contains an atomic data member via the C11 '_Atomic' approach, the front end crashes with a null pointer dereference.
This patch fixes it by guarding the null dereference with the approach used by similar code in the same method.
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1135 | I would prefer: if (MemberExpr *ME2 = dyn_cast<MemberExpr>(RHS)) { if (ME2->getMemberDecl() == Field) return Field; } return nullptr; |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1135 | I see that change removes the dyn_cast<FieldDecl>. Was that intended, or an oversight? In terms of changing the code-structure, in code on it's own, I do like the approach you described. But in this case, there is a sequence of if (<condition1>) return nullptr; ... if (conditionN) return nullptr; return Field;. Then after the block containing that set of guarded nullptr returns with a final return Field;, there is a similar block. And then there is a third block with a similar set. So changing the structure in that way breaks that pattern. With that in mind, do you still want that change done? |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1135 | The dyn_cast has no effect. There is no situation in which the declarations would compare equal without it where they would not with it, because Field is already known to be a FieldDecl. The structure of the existing code is unlikely to stay the same. Actually, that code is quite worrying — it's making a lot of assumptions about how Sema synthesizes defaulted assignment operator bodies. But I didn't want to ask you to fix it when it's not the subject of your bug. |
lib/CodeGen/CGClass.cpp | ||
---|---|---|
1135 | Got it. Posted updated patch. |
I would prefer: