When running with the interpreter on Darwin, force the usage of the just built, stdlib when running the frontend. #37771
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci smoke test |
|
@swift-ci test Apple Silicon |
gottesmm
force-pushed
the
pr-68240f777a82206ee3ac630da53e83f266bb4f48
branch
from
5db9c9d to
c88b6c8
Compare
|
Discovered an interpreter test that did not use target-jit-run (where the fix is). |
|
@swift-ci test |
|
@swift-ci test Apple Silicon |
gottesmm
force-pushed
the
pr-68240f777a82206ee3ac630da53e83f266bb4f48
branch
2 times, most recently
from
0c982f2 to
d2491b5
Compare
|
@swift-ci test |
|
@swift-ci test apple silicon |
…ust built, stdlib when running the frontend. 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
gottesmm
force-pushed
the
pr-68240f777a82206ee3ac630da53e83f266bb4f48
branch
from
d2491b5 to
524c5e0
Compare
|
@swift-ci test apple silicon |
|
@swift-ci test |
benlangmuir
approved these changes
Jun 3, 2021
| // RUN: %target-jit-run -interpret %s | %FileCheck %s -check-prefix=CHECK-NONE | ||
| // RUN: %target-jit-run -interpret %s -Onone -g | %FileCheck %s -check-prefix=CHECK-NONE | ||
| // RUN: %target-jit-run -interpret %s -Onone -g -- | %FileCheck %s -check-prefix=CHECK-NONE | ||
| // RUN: %target-jit-run -interpret %s -Onone -g -- a b c | %FileCheck %s -check-prefix=CHECK-THREE |
There was a problem hiding this comment.
These can drop -interpret
| @@ -1891,6 +1885,17 @@ if not kIsWindows: | |||
| "SIMCTL_CHILD_DYLD_LIBRARY_PATH='{0}' " # Simulator option | |||
| .format(all_stdlib_path, libdispatch_path)) + config.target_run | |||
|
|
|||
| subst_target_jit_prefix = "" | |||
| if platform.system() == 'Darwin' and config.target_run: | |||
There was a problem hiding this comment.
At one point you had a big comment about why this was needed; it would be nice to resurrect that.
|
I'll fix both of these once it lands. |
lhames
approved these changes
Jun 3, 2021
gottesmm
added a commit
to gottesmm/swift
that referenced
this pull request
Jun 6, 2021
gottesmm
added a commit
that referenced
this pull request
Jun 9, 2021
…bd410a6b620245 Fixes in response to feedback on #37771.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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