[pull] swiftwasm from master #1033
Closed
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}
… IterableDeclContext
Platform defines sem_open in Swift that calls through to the underlying platform functions because sem_open is variadic. However, the definitions here assume sem_t is non-nullable, but this assumption only holds when the platform has nullability annotations on the semaphore type, or the semaphore type on the platform is not an opaque pointer. On OpenBSD specifically, the semaphore type is an opaque pointer without any nullability annotations. This means that the type gets inferred as UnsafeMutablePointer<sem_t?>? instead of UnsafeMutablePointer<sem_t>?. To make sure the pointer values returned and their types match, we introduce a conditional typealias. The other option is to coerce everything to UnsafeMutablePointer<sem_t>? but this would be a rather blunt instrument. While sem_open is public in stdlib, it is not so much codified stdlib API, so this is a slightly nicer approach.
The correct usage of "-SAME" is after the check-prefix, not in the middle. I've updated the constants to what is emitted today. Now with verified 32-bit fixes.
Even if a store is not dominating the loop exits, it makes sense to move it out of the loop if the pre-header also as a store to the same memory location. When this is done, dead-store-elimination can then most likely remove the store in the pre-header.
Following swiftlang#31125 and swiftlang#31612, `-target` is not added automatically to linker flags when that's needed (e.g. when building for Apple SDKs) -- mimic the logic used to add it for compiler flags. Addresses rdar://63138761
Permit the directory style `.swiftmodule` on non-Apple targets. This allows all platforms to use the directory layout enabling multi-architecture SDKs. This not only unifies the layout of the SDK across the various targets, it also enables Windows to have a single unified SDK. The complexity here is due to the compatibility for older layouts. This change does not break compatibility on Linux/Android/Windows for the old style layout.
LICM: enable more stores to moved out of a loop
[update-checkout] swift-argument-parser 0.0.5 -> 0.0.6
This removes the last reference to the `llvm::` namespace in the standard library. All uses of the LLVMSupport library now are namespaced into the `__swift::__runtime` namespace. This allows us to incrementally vend the LLVMSupport library and make the separation explicit.
Adjust the test to care for environments which cannot handle direct references across modules. This field needs to be filled in at runtime.
…rabledc [NFC] AST: Relocate some conformance lookup client methods from DeclContext to IterableDeclContext
…s_OpenBSD [stdlib] sem_t is a nullable pointer on OpenBSD.
Similar to swiftlang#28486 in motivation. Before this change 'count' got lowered to multiple 'endIndex' calls Fixes rdar://46702232
Add a test to ensure that the standard library does not accidentally end up with symbols in the `llvm::` namespace. The LLVMSupport symbols for now are namespaced to `__swift::__runtime` with the desire that they will move into `swift::` and become vended in the swift namespace.
build: remove last `llvm::` reference in stdlib
I don't see any reason to split the tests like this. I merged the tests into the biggest and best-organized test file. I also removed the `REQUIRES: OS=macosx` line and made some small adjustments to the test to make it cross-platform.
This forces it to be inlined even in cold paths
This restores getSourceRange() on DefaultArgumentExpr after it was removed in swiftlang#31184. It was originally removed to solve the issues it was causing when computing the source range of its parent TupleExpr. To account for trailing closures we walk back through the tuple's arguments until one with a valid location is found, which we use as the end location. If the last argument was a DefaultArgumentExpr though that meant the end loc would end up being the tuple's start location, so none of the tuple's other arguments were contained in its range, triggering an ASTVerifier assertion. Source tooling and diagnostics don't care about default arg expression locations as nothing can reference them, but their locations are output in the debug info. Added a regression test to catch that in future, and updated TupleExpr::getSourceRange() to ignore them when computing the end loc. Resolves rdar://problem/63195504.
Allow empty input as PE/COFF does not provide a symbol table which results in no visible symbols.
[IRGen testing] Reapply: Fix bogus FileCheck check-prefix "-SAME" usage
This diagnostic logic is currently called from `finishTypeChecking`, however it doesn't need to be delayed until after all the source files have been type-checked, only after they have all had their imports resolved. It can therefore be lifted into a request that operates on a ModuleDecl, and be called from TypeCheckSourceFileRequest. Being a request will ensure that the pass is only run once across the module. Eventually we'll probably want to re-do import resolution so that it operates on an entire module. At that point, we'll want to look at integrating this diagnostic logic into it.
[Diagnostics] Rely on clang headers for .dia block and record IDs
Invert if statement in filesystem for clearer intent.
…hone-5 [docs] Update Testing.md
…Quadrature.swift Fixes example snippets in Quadrature.swift
…-source-loc [AST] Restore getSourceRange() on DefaultArgumentExpr
The last reader of this bit was the legacy integrated REPL.
While refactoring in 48805b1, I accidentally added the computation of this bit before CompilerInstance::setupInputs is called. This means that the compiler currently does not have any knowledge of any primary input buffers, and thus the check for whole module mode is trivially true. As a consequence, this bit has been true ever since. Since we seem to have got on just fine without computing this correctly, just inline that truthiness everywhere. Whoops
We actually wanted to use forEachFileToTypeCheck, which will restrict the source files we analyze to just the given primaries in incremental mode, and the whole module's source files otherwise.
…r-swift-master-next
[NFC] Clean Up Some Unneeded TypeCheckerOptions
Consolidated four CoreGraphics execution tests
[stdlib] Make non-native ArrayBuffer.capacity smaller
Fixes a compiler warning. NFC
test: ensure that we do not regress the standard library isolation
…fication Serialization: permit the directory layout on non-Apple targets
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 : )