-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Update in-source documentation. #2732
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
Closed
ElektrojungeAtWork
wants to merge
24
commits into
swiftlang:master
from
ElektrojungeAtWork:Fork/improvement/update-source-docs-to-master
Closed
Update in-source documentation. #2732
ElektrojungeAtWork
wants to merge
24
commits into
swiftlang:master
from
ElektrojungeAtWork:Fork/improvement/update-source-docs-to-master
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
`InMemoryGitRepository` is initialized with a path and a in-memory file system where it belongs. It then creates seperate in-memory file systems for each of its commits. Previously, the contents of the repository in the commit file systems was at the same location as in the working directory file system, which caused issues when cloning the repository to a different location on the file system (in installHead). Now, the contents of the repository in the commit file systems is located at root.
…e bundle, it should emit a fatal error rather than crashing the process with a force-unwrap (cherry picked from commit 33d4375)
[5.3] Don't use force unwrap in the code generated for looking up the module resource bundle
Update CODEOWNERS for 5.3 release branch
… separately from the stdout (swiftlang#2683) Manifests can emit output to stdout (useful for debugging purposes). The earlier switch from an interpreted to a compiled manifest caused this output to no longer be captured; and more seriously, if enough stdout output was emitted to fill the stdout buffer (or if buffering was disabled), then the stdout output would interfere with the emitted JSON description of the package manifest. This change causes the JSON to again be emitted to a separate file so that there is no interference with stdout output, restoring the behavior of when the manifest was interpreted. There are possible various error conditions that the existing code doesn't handle, and this change doesn't improve on that (it also doesn't make it worse). A future change should consider making those cases more robust, although it may be of limited practical use, since this is an internal contract between two pieces of code. However, it would be good to have better diagnostics in the case of I/O errors or other environmental problems. (cherry picked from commit ab8d72c)
[5.3] [SR-12553] [ManifestLoader] Capture JSON output from a manifest separately from the stdout
…or JSON output, to avoid revlock between libSwiftPM and PackageDescription This restores the functionality prior to SR-12553, while also keeping the separation between stdout and the JSON output emitted by the package manifest. It still uses a file in the file system for the JSON, but goes back to having it be opened by the caller of the manifest, passing the file descriptor down to the manifest process as before the switch from interpreted to compiled manifests. Unit test added for SR-12553 still provides test coverage. (cherry picked from commit bd4f8f6)
[5.3] [SR-12613] [ManifestLoader] Go back to using `-fileno` option for the separate JSON output
…known files in pre-5.3 manifests (cherry picked from commit 3f63a2d)
[5.3] Fix a SwiftPM 5.2 regression that cause it to try to compile unknown files in pre-5.3 manifests
This should be clearer than the original diagnostic and also provides the checksums as part of the message for easy copy-paste if it is simply out of date. rdar://problem/60618054 (cherry picked from commit a3f91ee)
So far we have only been processing resources if they are in a folder that has explicitly been declared as a resource, but we should do it by default. rdar://problem/61957063 (cherry picked from commit 0eda5ce)
…-to-master # Conflicts: # CODEOWNERS # Sources/PackageDescription/SupportedPlatforms.swift # Sources/PackageDescription/Target.swift # swift-tools-support-core/Sources/TSCUtility/Versioning.swift
I'm a bit surprised that a bunch of unrelated commits are shown here, maybe this needs a rebase or something? |
@neonichu Damn, sorry, I messed this one up. I did all the work on the branch for 5.3 and forgot that it's not the same as master. I'll create a new PR. |
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 the same PR as #2715 but targets master.