Skip to content

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

Conversation

ElektrojungeAtWork
Copy link
Contributor

This is the same PR as #2715 but targets master.

hartbit and others added 24 commits April 9, 2020 15:08
`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
… 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
@neonichu
Copy link
Contributor

neonichu commented May 6, 2020

I'm a bit surprised that a bunch of unrelated commits are shown here, maybe this needs a rebase or something?

@ElektrojungeAtWork
Copy link
Contributor Author

@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.

@ElektrojungeAtWork ElektrojungeAtWork deleted the Fork/improvement/update-source-docs-to-master branch May 7, 2020 05:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants