This is because we currently JIT in process resulting in weirdness around
swift-frontend wanting to link against the host stdlib and the exec swift code
wanting to link against the target stdlib. For now, we work around this by just
saying in that case we will force swift-frontend to use the just built runtime
so we are consistent. The only potential problem is that a bug in the just built
runtime may now cause these tests to fail. But overall, that would suggest a
problem we may want to catch in it of itself, so the work around I think makes
sense until JITing is done in a separate process (which I think is the right fix).
rdar://78768013
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
In the frontend, only arguments after '--' will be passed as arguments
to the new process. Also, add the input filename as argv[0], to follow
the usual conventions.
Still to come is fixing swift -i from the driver.
Swift SVN r19690
