[pull] swiftwasm from main #1829
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}
The `env -u` flag is not portable and not available on all platforms, so this unit test will fail when the feature is unavailable. Instead of trying to unset the field, just erase it instead, since trying to copy the entire invoked environment is difficult.
…th covariant Self
See SR-12893. swift-reflection-dump does not properly handle offsets in ELF executable images that, when interpreted as vaddrs, belong in segments part of the image. This just empirically XFAIL's the unit tests that are crashing or failing, even though the other tests are just happening to pass anyway. There's no clear workaround; disable the expected failures for the moment.
It might contain archetypes whose type metadata is required. rdar://68972976 SR-13555
This ensures that we erase opened archetypes before closing an existential result
Bindings are not visible from inside their own initializer, eg this is invalid: var (x, y) = (y, x) The PatternEntryDeclScope which starts after the 'var' introduces x and y, and it contains the PatternEntryInitializerScope which starts after the '='. To model this properly in ASTScope, the PatternEntryInitializerScope overrides getLookupParent() to skip the PatternEntryDeclScope that contains it. I believe this is simpler than having PatternEntryDeclScope begin at the source location following the initializer, because it is hard to compute this source location in a way that works with invalid code, for example the 'var' might be nested inside of a BraceStmt with the closing '}' missing.
… bindings This gives us the desired behavior, where local bindings are in scope after their definition. Note that BraceStmt still introduces all bindings at the beginning, but now we change BraceStmt to only introduce local functions and types, allowing us to disable parse-time lookup.
This grants access to the name of the loaded file to clients, which will be important for the upcoming cross-module incremental build experiments.
Strip mention of the SourceFile. Any FileUnit-esque thing that can provide top-level decls and `lookupClassMembers` works here - especially a ModuleDecl.
We thought we would need this while exploring certain pre-build optimizations a la rdar://problem/37725110. This information was never used.
This better reflects the actual structure of the files as they appear in the 10.15 and 10.15.4 SDKs respectively. rdar://69412779
…ut_profile_sil_type IRGen: Scalar type layouts need to profile the SIL type
[NFC] Some Uncontroversial Frontend Refactorings
Infer @asyncHandler on a protocol methods that follow the delegate convention of reporting that something happened via a "did" method, so long as they also meet the constraints for an @asyncHandler method in Swift. This enables inference of @asyncHandler for witnesses of these methods.
Remove ~moduleonly Duplicate of Compilation Record
Fixup Structure of Mock SDKSettings
[ownership] Convert OME into a function pass
ASTScope: Take start location into account when modeling local pattern bindings
Stage in Frontend/Driver Feature Flags for Cross-Module Incremental Builds
Take advantage of the binary swiftdeps serialization utliities built during swiftlang#32131. Add a new optional information block to swiftdeps files. For now, don't actually serialize swiftdeps information. Frontends will use this information to determine whether to write incremental dependencies across modules into their swiftdeps files. We will then teach the driver to deserialize the data from this section and integrate it into its incremental decision making.
This has the net effect of only recording cross-module dependency information in the current module if the module under scrutiny can possibly provide dependency information of its own. For now, because none of this is turned on, this does not actually record additional dependencies from extant modules.
Invert the responsibility of the entrypoint so that FrontendTool is directing the actual serialization work. The entrypoint now solely exists to construct a dependency graph. While I'm here, prepare the way for serializing dependency graphs for modules by optimistically modeling a ModuleOrSourceFile input.
Sema: Allow non-final classes to satisfy properties and subscripts with covariant Self
…synchandler-inference [Concurrency] Import "did" delegate methods as @asyncHandler.
* Move OME after CopyForwarding * Minor fix in CopyForwarding test
Serialization for Incremental Swift Dependency Information
kateinoigakukun
approved these changes
Sep 25, 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 : )