Manual merge 2020/10/08 #1959
Merged
Manual merge 2020/10/08 #1959
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
This reverts commit 3a48396110d2639d7b90970bc0369a559adbc0c1.
The handling of "global" missing witnesses would diagnose a missing witness (showing "almost" matches) and then, later, provide the Fix-It to add the declaration if the user wants it. Delay the diagnostic part until later, when we add the missing witness. While here, correct an existing issue with memory corruption that occurs because we would diagnose some of these witnesses, then clear a "global" witness list, while still iterating through parts of that list.
The Clang importer was filtering out cases where the same declaration is imported twice under the same name, which can now happen when one is synchronous and one is asynchronous. This happens when, e.g., an Objective-C class provides both a completion-hander-based asynchronous version and a synchronous version, and the Swift names line up after the completion-handler parameter is dropped. Stop filtering these out. Overload resolution is capable of handling synchronous/asynchronous overloading based on context.
…selector. When concurrency is enabled, the same Objective-C method on a protocol can be imported as two different protocol requirements, both of which have the same selector. When performing conformance checking, only treat a given @objc protocol requirement as "unsatisfied" by a conformance if none of the requirements with the same Objective-C selector (+ instance/class designation) are satisfied.
…sses. Actor classes are by definition new code, so only perform inference of @asyncHandler from a protocol requirement to witnesses when those witnesses are within an actor class. This is partly because @asyncHandler might not have reasonable semantics outside of actor classes anywhere (where would you execute the detached task?), and partly because it is a source-compatibility problem due to the combination of... 1) Inferring @asyncHandler on imported Objective-C protocol methods for existing protocols, 2) Inferring @asyncHandler from those protocol methods to an existing method in a class that conforms to that protocol, and 3) Using an API that is now overloaded for both synchronous and asynchronous callers will end up preferring the asynchronous version, then fail due to a missing "await". The individual steps here are all reasonable, but the result is a source break, so back off on @asyncHandler inference for witnesses outside of actor classes. New code gets the more-asynchronous behavior for free.
With actor isolation checking for protocol witnesses moved out of the witness-matching phase, move the corresponding diagnostics from notes (that would have been on the "type does not conform" error) to freestanding errors.
The install-swift-driver phase knows how to build swift-driver using CMake. Allowing only install-swift-driver without plain swift-driver allows installing it without requiring swiftpm.
I needed to use these and realized they were not documented here. I had them in my brain, but others may not, so seemed good to do.
… interface This is for testing purposes to ensure prebuilt modules are up to date. rdar://68770805
The bare "PATTERN" argument by default does nothing, you need either "EXCLUDE" or "FILES_MATCHING" to make it do something. This likely wasn't previously a problem because clang is only installing headers, but it should be fixed for robustness.
llvm-bcanalyzer does *not* like it when there are multiple block info metadata blocks in the same bitstream file. This patch will skip the emission of that and just jump straight to the metadata block when we're not reading a "standalone" incremental dependency file. While I'm here, also add the right block abbreviation info so we can get a decent dump from llvm-bcanalyzer
…pendencies Register the module the external dependencies ride in with the pseudo-job in the Driver. This is a hack.
Cross-Module incremental dependencies are a new experimental mode of the Swift driver and frontend. Through a tight partnership between the two, we enable the driver to have far greater visibility into the dependency structure of a Swift module. Rather than invent a new model, we have chosen to extend the existing incremental compilation model that works for a single module to multiple modules. To do this, we need the frontend to emit Swift dependencies in a form the driver can consume. We could emit these metadata in the form of an extra supplementary output that summarizes the contents of a generated module. However, this approach comes with a number of downsides: - It requires additional integration with the build system - It assumes swiftmodule files will be consumed directly from the build directory; they are not - It incorrectly assumes a swiftmodule has but one interface. Taken in aggregate, a swiftmodule directory has one interface *per triple* Given this, the approach we take here is to encode these dependencies directly into the swiftmodule file itself. When frontends load these souped-up incremental swiftmodule files, they record in their own swiftdeps files that they depend on an incremental swiftmodule. Upon the next build, the driver is then able to read that module file, extract the swiftdeps information from it, and use it to influence the way it schedules jobs. The sum total is that we neatly extend the intra-module case of incremental builds to the inter-module case by treating swiftmodule inputs not as opaque entities, but as "big ol' flat Swift files" that just export an interface like any other Swift file within the module. As a further optimization, and because clients literally cannot observe this aspect of the incremental build, we only serialize the provides (the "defs" side of a "use-def" edge) when emitting swiftdeps metadata into swiftmodule files. rdar://69595010
Here, the following is implemented: - Construction of SwiftContext struct with the fields needed for calling functions. - Allocating and deallocating these swift context via runtime calls before calling async functions and after returning from them. - Storing arguments (including bindings and the self parameter but not including protocol fields for witness methods) and returns (both direct and indirect). - Calling async functions. Additional things that still need to be done: - protocol extension methods - protocol witness methods - storing yields - partial applies
…en/signature [Concurrency] Async CC, part 1.
…link-errors [AST] Fix linker errors with the parser-only build
Fixed docs link to Rust's demand-driven compilation guide
…wiftlang#34197) Previously it was enable only for swift/stdlib/public/core
…tching-pattern [build] Add FILES_MATCHING to CMakeLists.txt
Previously, the polymorphic arguments were being discarded. Here, that situation is improved by pulling the polymorphic arguments out of the explosion when having the polymorphic parameters via the NecessaryBindings instance. In order to eanble that, an overload of NecessaryBindings::save is added which takes an explosion and asserts that the polymorphic parameter pulled from the explosion matches with the polymorphic parameter in the NecessaryBindings instance.
The fake job is entered into the map to satisfy the tracing machinery. When that same machinery kicks into gear to print out paths, lookups into the dictionary will access data has gone out of scope. For now, cut off the read. There will be another refactoring patch that keeps these temporaries out of the Driver's data structures entirely. rdar://70053563
Patch Out Use-Of-Stack-After-Free In Cross Module Dependencies
A more durable form of swiftlang#34218. Keep a side cache of externally-dependent jobs for now. This ensures our pseudo-Jobs don't get prematurely deallocated before the tracing machinery has had a chance to report the structure of the Job graph. rdar://70053563
The original remark message “could not acquire lock file for module interface” sounds too severe. It may confuse users that this is a serious issue. We should rephrase it to a less obtrusive one. rdar://70055223
The tests IRGen/async/run-* all link against a PrintShims dylib. To force that dylib to be copied onto devices running these tests, add the dylib's path to the %target-run line.
[Sema] Decouple ConstraintSystem and TypeChecker headers
This will be used to extend incremental behavior to merge-modules and the bridging header precompile step.
This function was being used in a roundabout way to test for a compile job action. But the actual data itself was not being used.
…ange-fixes ASTScope: Pre-compute the right source ranges instead of relying on widening
[OSSignpost] Update apinotes to allow usage of os_signpost ABI entrypoint
…en/protocol-witness-methods [Async CC] Support for protocol witness methods.
…en/test-copies-dylib [Test] Ensure linked dylib is copied to devices.
WinSDK: extract Security submodule with winscard.h
The Optional parameter here was being copied instead of being taken by const reference. The expectation is that we call this function and extract the data from a ModuleDepGraphNode node, but instead we were extracting a copy which would promptly blow up. Thanks ASAN!
ModuleInterface: rephrase remark message when acquiring lock file failed
Keep a Cache of Externally-Dependent Jobs
…rce-ranges Migrate ASTScope to CharSourceRanges
The default package of `apt install clang` is clang-6 and it overwrite default installed clang 9.0
|
Please cherry-pick 63a7ae3 into 5.3 branch 🙏 |
|
Cherry-picked in #1949 🙂 |
|
Thanks! |
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.
No description provided.