[all-commits] [llvm/llvm-project] 322085: [Modules] Do not remove failed modules after the c...

[Ben Barham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 32208555af26c48f3df845a10b049c8eb74e2eb3
      https://github.com/llvm/llvm-project/commit/32208555af26c48f3df845a10b049c8eb74e2eb3
  Author: Ben Barham <ben_barham at apple.com>
  Date:   2021-08-17 (Tue, 17 Aug 2021)

  Changed paths:
    M clang/lib/Serialization/ASTReader.cpp
    R clang/test/VFS/Inputs/UsesFoo.framework/Headers/UsesFoo.h
    R clang/test/VFS/Inputs/UsesFoo.framework/Modules/module.modulemap
    A clang/test/VFS/module-header-mismatches.m
    R clang/test/VFS/umbrella-mismatch.m

  Log Message:
  -----------
  [Modules] Do not remove failed modules after the control block phase

Reading modules first reads each control block in the chain and then all
AST blocks.

The first phase is intended to find recoverable errors, eg. an out of
date or missing module. If any error occurs during this phase, it is
safe to remove all modules in the chain as no references to them will
exist.

While reading the AST blocks, however, various fields in ASTReader are
updated with references to the module. Removing modules at this point
can cause dangling pointers which can be accessed later. These would be
otherwise harmless, eg. a binary search over `GlobalSLocEntryMap` may
access a failed module that could error, but shouldn't crash. Do not
remove modules in this phase, regardless of failures.

Since this is the case, it also doesn't make sense to return OutOfDate
during this phase, so remove the two cases where this happens.

When they were originally added these checks would return a failure when
the serialized and current path didn't match up. That was updated to an
OutOfDate as it was found to be hit when using VFS and overriding the
umbrella. Later on the path was changed to instead be the name as
written in the module file, resolved using the serialized base
directory. At this point the check is really only comparing the name of
the umbrella and only works for frameworks since those don't include
`Headers/` in the name (which means the resolved path will never exist)

Given all that, it seems safe to ignore this case entirely for now.
This makes the handling of an umbrella header/directory the same as
regular headers, which also don't check for differences in the path
caused by VFS.

Resolves rdar://79329355

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