Skip to content

Commit 02c7476

Browse files
committed
Preload standard library in ModuleInterfaceBuilder
Previously, when the standard library module interface was broken, Swift would try to rebuild it repeatedly during -compile-module-from-interface jobs because `ASTContext::getStdlibModule()` would try to load the standard library again each time it was called. This led to extremely slow compilations that repeatedly emitted the same errors. To avoid this, we make ModuleInterfaceBuilder try to load the standard library right away and bail out if it can’t. Fixes rdar://75669548.
1 parent 1f71307 commit 02c7476

File tree

5 files changed

+37
-0
lines changed

5 files changed

+37
-0
lines changed

lib/Frontend/ModuleInterfaceBuilder.cpp

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -187,6 +187,13 @@ bool ModuleInterfaceBuilder::buildSwiftModuleInternal(
187187
InputInfo.getPrimarySpecificPaths().SupplementaryOutputs;
188188
StringRef OutPath = OutputInfo.ModuleOutputPath;
189189

190+
// Bail out if we're going to use the standard library but can't load it. If
191+
// we don't do this before we try to build the interface, we could end up
192+
// trying to rebuild a broken standard library dozens of times due to
193+
// multiple calls to `ASTContext::getStdlibModule()`.
194+
if (SubInstance.loadStdlibIfNeeded())
195+
return std::make_error_code(std::errc::not_supported);
196+
190197
// Build the .swiftmodule; this is a _very_ abridged version of the logic
191198
// in performCompile in libFrontendTool, specialized, to just the one
192199
// module-serialization task we're trying to do here.
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
// swift-interface-format-version: 1.0
2+
// swift-module-flags: -target x86_64-apple-macos10.9 -module-name BadStdlib
3+
4+
// no-error@-3
5+
6+
// Tests whether -compile-module-from-interface correctly stops early when the
7+
// standard library module interface is broken, rather than trying to limp along
8+
// without a standard library, which tends to cause ClangImporter crashes (among
9+
// other things.)
10+
11+
// RUN: %empty-directory(%t)
12+
// RUN: %target-swift-frontend(mock-sdk: -sdk %/S/Inputs/BadStdlib.sdk -module-cache-path %/t/module-cache -resource-dir %/S/Inputs/BadStdlib.sdk) -compile-module-from-interface -o %/t/BadStdlib.swiftmodule %s -verify -verify-additional-file %/S/Inputs/BadStdlib.sdk/usr/lib/swift/Swift.swiftmodule/x86_64-apple-macos.swiftinterface
13+
14+
import ClangMod
15+
16+
public func useHasPointer(_: HasPointer)
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
typedef int * HasPointer;
Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
module HasPointer {
2+
header "HasPointer.h"
3+
export *
4+
}
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
// swift-interface-format-version: 1.0
2+
// swift-module-flags: -target x86_64-apple-macos10.9 -module-name Swift -parse-stdlib
3+
4+
// If the test fails, this error will be emitted twice, not once.
5+
// expected-error@-4 {{failed to build module 'Swift' for importation due to the errors above}}
6+
7+
public struct BadType {
8+
public var property: UndeclaredType { get set } // expected-error {{cannot find type 'UndeclaredType' in scope}}
9+
}

0 commit comments

Comments
 (0)