Avoid adding any framework paths in /System/Library in process_one_mo…

[adrian-prantl]

…dule.

The merit of process_one_module can be debated, but these are
definitely wrong, system modules must be imported from the SDK instead.

rdar://problem/56280346

(cherry picked from commit cf073c765b031ae73f96f2f2a4a5f75bb4981c8f)

[adrian-prantl]

@swift-ci test

[jimingham]

There's a bunch of code just above the bit you turned off that is supposed to avoid adding any Frameworks to the search path that lack Headers and/or Modules directories.

Nothing in /System/Library has Headers or Modules directories (and haven't for quite a while). I wonder why that pass didn't reject these paths - i.e. why was add_it true in the first place?

[adrian-prantl]

Good point. The only other place that could be it is

        if (ast_context && !ast_context->HasErrors()) {
          if (use_all_compiler_flags ||
              target.GetExecutableModulePointer() == module_sp.get()) {

            const auto &opts = ast_context->GetSearchPathOptions();
            module_search_paths.insert(module_search_paths.end(),
                                       opts.ImportSearchPaths.begin(),
                                       opts.ImportSearchPaths.end());
            for (const auto &fwsp : opts.FrameworkSearchPaths)
              framework_search_paths.push_back({fwsp.Path, fwsp.IsSystem});

            swift_ast_sp->AddExtraClangArgs(ast_context->GetClangArguments());
          }

but the logs don't back that up either.

[adrian-prantl]

For those following at home, we have identified systems in the wild that do have older header files in /System/Library/Frameworks that presumably were carried forward through system upgrades.