Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[old-llvm] [5.1] Module filename and location changes #23039

Merged
merged 10 commits into from Mar 2, 2019

Conversation

Projects
None yet
2 participants
@brentdax
Copy link
Collaborator

brentdax commented Mar 2, 2019

Manual merge of #23021, which cherry-picked #21797, #22907, and #22907, into 5.1-old-llvm. Sigh.

jrose-apple and others added some commits Feb 19, 2019

On Apple platforms, use swiftmodule directories for the stdlib (#21797)
This changes the Swift resource directory from looking like

    lib/
      swift/
        macosx/
          libswiftCore.dylib
          libswiftDarwin.dylib
          x86_64/
            Swift.swiftmodule
            Swift.swiftdoc
            Darwin.swiftmodule
            Darwin.swiftdoc

to

    lib/
      swift/
        macosx/
          libswiftCore.dylib
          libswiftDarwin.dylib
          Swift.swiftmodule/
            x86_64.swiftmodule
            x86_64.swiftdoc
          Darwin.swiftmodule/
            x86_64.swiftmodule
            x86_64.swiftdoc

matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).

There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.

rdar://problem/43545560
[NFC] Clean up module name pairs
Create a helper type to represent the .swiftmodule/.swiftdoc filename pair and use it in SerializedModuleLoaderBase::findModule().
[NFC] Generalize target-specific module loading…
…from 1-2 target-specific names to 0-N target-specific names.
Use target triple for “universal” modules
When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
[NFC] Restyle getTargetSpecificModuleTriple()
* Adds documentation comments.
* Turns redundant cases into comments.
* Removes the else branch in a couple “if (…) return …; else return …;” patterns.
[test] Fix loaded_module_trace.swift for arch's that sort before "M" (#…
…22907)

This field is reverse-path-sorted, so the order depends on what
architecture we're compiling for. That's not what's being tested,
so just use a CHECK-DAG.

rdar://problem/48377454
Merge pull request #23021 from brentdax/target-practice-5.1
[5.1] Module filename and location changes
Brent Royal-Gordon
Merge branch 'swift-5.1-branch' into swift-5.1-old-llvm-branch
# Conflicts:
#	lib/Serialization/SerializedModuleLoader.cpp
@brentdax

This comment has been minimized.

Copy link
Collaborator Author

brentdax commented Mar 2, 2019

@swift-ci please smoke test and merge

@brentdax

This comment has been minimized.

Copy link
Collaborator Author

brentdax commented Mar 2, 2019

Build failures are in lldb; I don't see how I could have caused those.

@brentdax brentdax merged commit 3b3939d into apple:swift-5.1-old-llvm-branch Mar 2, 2019

0 of 3 checks passed

Swift Test Linux Platform (smoke test)
Details
Swift Test OS X Platform (smoke test)
Details
Test and Merge (smoke test) Build finished.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.