[all-commits] [llvm/llvm-project] 9fad9d: [modules] Fix IRGen assertion on accessing ObjC iv...

[Volodymyr Sapsai via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9fad9de5c0032898a481e06bf5f696ca50c804c1
      https://github.com/llvm/llvm-project/commit/9fad9de5c0032898a481e06bf5f696ca50c804c1
  Author: Volodymyr Sapsai <vsapsai at apple.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M clang/include/clang/AST/DeclObjC.h
    M clang/lib/AST/RecordLayoutBuilder.cpp
    M clang/lib/Serialization/ASTReaderDecl.cpp
    A clang/test/Modules/merge-objc-interface.m

  Log Message:
  -----------
  [modules] Fix IRGen assertion on accessing ObjC ivar inside a method.

When have ObjCInterfaceDecl with the same name in 2 different modules,
hitting the assertion

> Assertion failed: (Index < RL->getFieldCount() && "Ivar is not inside record layout!"),
> function lookupFieldBitOffset, file llvm-project/clang/lib/AST/RecordLayoutBuilder.cpp, line 3434.

on accessing an ivar inside a method. The assertion happens because
ivar belongs to one module while its containing interface belongs to
another module and then we fail to find the ivar inside the containing
interface. We already keep a single ObjCInterfaceDecl definition in
redecleration chain and in this case containing interface was correct.
The issue is with ObjCIvarDecl. IVar decl for IRGen is taken from
ObjCIvarRefExpr that is created in `Sema::BuildIvarRefExpr` using ivar
decl returned from `Sema::LookupIvarInObjCMethod`. And ivar lookup
returns a wrong decl because basically we take the first ObjCIvarDecl
found in `ASTReader::FindExternalVisibleDeclsByName` (called by
`DeclContext::lookup`). And in `ASTReader.Lookups` lookup table for a
wrong module comes first because `ASTReader::finishPendingActions`
processes `PendingUpdateRecords` in reverse order and the first
encountered ObjCIvarDecl will end up the last in `ASTReader.Lookups`.

Fix by merging ObjCIvarDecl from different modules correctly and by
using a canonical one in IRGen.

rdar://82854574

Differential Revision: https://reviews.llvm.org/D110280