Is it reliable to check if Process.arguments[0].lowercased() == "swift"?

It isn't, unfortunately. Script mode sets Process.arguments[0] to the name of the script. Since this is for an internal tool, though, it doesn't have to be clean; maybe it's good enough to check if the string ends with ".swift"?

Note that "the interpreter" is different from "the integrated REPL" (and definitely different from "the real, LLDB-provided REPL"). The mode I'm referring to is swift foo.swift.

Wait, shouldn't --stdlib-unittest-in-process imply skipping crash tests? Or should there be an explicit, separate option?

That's a good @gribozavr question, but I think that's the flag that says "yes, please crash; the parent process will pick it up". But we also want to do this without extra options, so that we don't have to change the RUN lines between compile/run and interpret builds.

I think the argument you're thinking of is --stdlib-unittest-run-child but I definitely understand wanting it to Just Work™. I'll try some things out. Thanks!

The way I imagined we would run tests in the interpreter is by teaching StdlibUnittest to run the subprocess with the interpreter correctly. Then everything will just work.

> Wait, shouldn't --stdlib-unittest-in-process imply skipping crash tests?

I'd say no. This option is very useful for running individual tests under the debugger, so it shouldn't disable tests by itself.

I agree, that makes more sense. However, I can't seem to find any way of knowing the interpreter path at runtime. I've looked all over.

Would this be a case for an environment variable like SWIFT_INVOCATION so we could maybe use that inside spawnChild?

    var pid: pid_t = -1
    var childArgs = [Process.arguments[0]] + args
    if let invocation = String(cString: getenv("SWIFT_INVOCATION")) {
      childArgs.insert(invocation, at: 0)
    }
    let spawnResult = withArrayOfCStrings(childArgs) { //... }

I thought the interpreter path is visible through argv[0]. If it is not, I don't mind an environment variable. I'd call it SWIFT_INTERPRETER though.

Unfortunately, argv[0] is just the filename of the test.

Should that invocation variable come from lit? Or how should it be set?

How about a #interpreter directive? 😉

I'd rather not have to go through swift-evolution to enable more tests. ;-)

Yes, the variable should be set by lit.

Re: #interpreter – let's not do language design 🙂

Well, what if we set the variable in Immediate.cpp:swift::RunImmediately? It gets the command line as a parameter, and would allow running one-off tests outside of lit.

That would change the compiler's behavior.

StdlibUnittest could include the environment variable into the command line that it suggests for debugging.

Ah, right. Didn't realize that was necessarily off-limits. 👍

Done? Great! But when?

Actually months ago, haha

d307e31

Ah, I missed this. Cool!

It doesn't work.

../llvm/utils/lit/lit.py -sv ../build/ninja/swift-macosx-x86_64/test-macosx-x86_64/1_stdlib --param interpret

(lots of crashes)

Hmm...this worked when I tried it in April. It's supposed to invoke a sub-interpreter when crashes are expected.

I'll investigate again...

So this specific issue is working correctly, but there are many test failures when running in the interpreter because of invariants that the interpreter doesn't satisfy.