[pull] swiftwasm from master #1056
Merged
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…sourceLocation is used - Always use the line number in the actual source file when extracting excerpts and adding highlights/fix-its - Always use the display name when printing excerpt titles - Don't print surrounding lines when an annotated line is in a virtual file This reverts commit f919e04.
…emitted in clang virtual files
- Compile will start / did finish now includes the operation kind (perform sema or code complete). - See also https://forums.swift.org/t/sourcekit-lsp-file-status-ux/35947
- `key.compile_operation` instead of `key.compileoperation` - Make the operation kind optional (nothing emitted for perform sema)
…pty field Introduce getByteOffsetDuringLayout() so that we can treat empty fields just like other fixed sized field while performing layout. rdar://62349871
in global completion result. Overly modules have the same name as the shadowed modules. We should not list both names because they are identical. Maintain a set of seen module names to avoid suggesting duplicated names. rdar://problem/63370253
Remove the bundled generated `llvm-config.h` as the options do not apply to the runtime usage for LLVMSupport. The configuration is known statically.
… RangeExpressions The previous documentation of this operator in `Range` context was lost sometime during 2017. This new version is a simplified version of the original copy, with substantial inspiration taken from the present-day documentation of the same operator on `Optional`. Fixes [SR-12842](https://bugs.swift.org/browse/SR-12842).
platform-module-dir isn't quite right, since we're looking for libswiftCore.dylib. rdar://problem/63437032
stdlib: remove `llvm-config.h` from swiftLLVMSupport
Rather than use `fprintf` for the error handling path use the platform specific error handling systems (`asl_log`, `__android_log_printf`) if available. The standard file streams are not available on all platforms (e.g. Android).
while investigating. rdar://problem/62923248
…atedmodule-rdar63370253 [CodeCompletion] Avoid suggesting duplicated module names
[SourceKit] Include operation kind in compile notifications
Removed support for iOS 8.2 and earlier from lit.cfg
…-match-op-missing-docs [SR-12842] Restore missing docs for RangeExpression.~=
Finish off private intransitive dependencies with an implementation of dependency replay. For the sake of illustration, imagine a chain of requests A -> B -> C -> ... Supposing each request is never cached, then every invocation of the compiler with the same inputs will always kick off the exact same set of requests. For the purposes of dependency tracking, that also means every single lookup request will run without issue, and all dependencies will be accurately reported. But we live in a world with cached requests. Suppose request B* is cached. The first time we encounter that request, its evaluation order looks identical: A -> B* -> C -> ... If we are in a mode that compiles single primaries, this is not a problem because every request graph will look like this. But if we are in a mode where we are compiling multiple primaries, then subsequent request graphs will *actually* hit the cache and never execute request C or any of its dependent computations! A -> B* Supposing C was a lookup request, that means the name(s) looked up downstream of B* will *never* be recorded in the referenced name tracker which can lead to miscompilation. Note that this is not a problem inherent to the design of the request evaluator - caches in the compiler have *always* hidden dependent lookups. In fact, the request evaluator provides us our first opportunity to resolve this correctness bug!
…-rdar62923248 [CodeCompletion] Disable fast-completion dependecy checking test cases
…lib-dir [Test] Have llvm-support-odr-violation.sh use platform-dylib-dir.
…ayout_empty_followed_by_nonfixed IRGen: Correctly compute the offset for a non-fixed field after an empty field
…urce-location-fixes
`@noDerivative` parameter mangling was added, so the test is not meaningful. The test occasionally flaked during CI, so it is better to remove it.
runtime: improve error handling path for the runtime
Split off the notion of "recording" dependencies from the notion of "collecting" dependencies. This corrects an oversight in the previous design where dependency replay and recording were actually not "free" in WMO where we actually never track dependencies. This architecture also lays the groundwork for the removal of the referenced name trackers. The algorithm builds upon the infrastructure for dependency sources and sinks laid down during the cut over to request-based dependency tracking in swiftlang#30723. The idea of the naive algorithm is this: For a chain of requests A -> B* -> C -> D* -> ... -> L where L is a lookup request and all starred requests are cached, once L writes into the dependency collector, the active stack is walked and at each cache-point the results of dependency collection are associated with the request itself (in this example, B* and D* have all the names L found associated with them). Subsequent evaluations of these cached requests (B* and D* et al) will then *replay* the previous lookup results from L into the active referenced name tracker. One complication is, suppose the evaluation of a cached request involves multiple downstream name lookups. More concretely, suppose we have the following request trace: A* -> B -> L | -> C -> L | -> D -> L | -> ... Then A* must see the union of the results of each L. If this reminds anyone of a union-find, that is no accident! A persistent union-find a la Conchon and Filliatre is probably in order to help bring down peak heap usage...
Naive Dependency Replay
iPhone 5 device does not come preconfigured in the latest Xcode (11.4.1).
…6-instructions Add instructions on how to create a 32-bit iOS simulator device
MaxDesiatov
approved these changes
May 21, 2020
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.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )