From b7ecd71d7513058558709213f8bb1f3a368e9120 Mon Sep 17 00:00:00 2001 From: David Nadlinger Date: Tue, 6 Nov 2012 23:16:50 +0100 Subject: [PATCH] Don't run inlining semantic3's on unit test builds. Fixes build of std.net.curl unit tests. --- driver/main.cpp | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/driver/main.cpp b/driver/main.cpp index 7db77e26..01ae6ad6 100644 --- a/driver/main.cpp +++ b/driver/main.cpp @@ -1015,8 +1015,24 @@ int main(int argc, char** argv) */ if (!global.params.useArrayBounds && !global.params.useAssert) #else - // This doesn't play nice with debug info at the moment - if (!global.params.symdebug && willInline()) + // This doesn't play nice with debug info at the moment. + // + // Also, don't run the additional semantic3 passes when building unit tests. + // This is basically a huge hack around the fact that linking against a + // library is supposed to require the same compiler flags as when it was + // built, but -unittest is usually not thought to behave like this from a + // user perspective. + // + // Thus, if a library contained some functions in version(unittest), for + // example the tests in std.concurrency, and we ended up inline-scannin + // these functions while doing an -unittest build of a client application, + // we could end up referencing functions that we think are + // availableExternally, but have never been touched when the library was built. + // + // Alternatively, we could also amend the availableExternally detection + // logic (e.g. just codegen everything on -unittest builds), but the extra + // inlining is unlikely to be important for test builds anyway. + if (!global.params.symdebug && willInline() && !global.params.useUnitTests) { global.params.useAvailableExternally = true; Logger::println("Running some extra semantic3's for inlining purposes");