forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
[pull] swiftwasm from main #5495
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
Merged
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
Lazy member loading has been in use and the default for several years now. However, the lazy loading was disabled for any type whose primary definition was parsed even though some of its extensions could have been deserialized, e.g., from a Clang module. Moreover, the non-lazy path walked all of the extensions of such a type for all member name lookup operations. Faced with a large number of extensions to the same type (in my example, 6,000), this walk of the list of the extensions could dominate type-checking time. Eliminate all effects of the `-disable-named-lazy-member-loading` flag, and always use the "lazy" path, which effectively does no work for parsed type definitions and extensions thereof. The example with 6,000 extensions of a single type goes from type checking in 6 seconds down to type checking in 0.6 seconds, and name lookup completely disappears from the profiling trace. The deleted tests relied on the flag that is now inert. They aren't by themselves providing much value nowadays, and it's better to have the simpler (and more efficient) implementation of member name lookup be the only one.
A recent refactoring uncovered two places where we could end up importing a C++ field declaration as a property more than once: 1. Importing the declaration context of a field in C++ mode can then go import all of the fields. In such a case, check that the field we're importing didn't happen already, and bail out early if it did. This is common practice in the Clang importer but wasn't happening here. 2. One caller to the function that imported a field from a C++ base class into its inheriting class (as a computed property) wasn't checking the cache, and therefore created a redundant version. Fix both issues.
…types The module-scope lookup tables use the same code for adding module-scope declarations as for adding member operators, which are found via "global" operator lookup. This requires us to expand macros that can produce members of types, which violates the outside-in expansion rule described in the proposals. Stop recording member-producing macros, whether they are peer macros applied to member declarations or are freestanding declaration macros within a member context. This re-establishes the outside-in expansion rule. It also means that member operators introduced by macro expansion won't be found by global operator lookup, which is a (necessary) semantic change.
When looking for an operator to satisfy a protocol requirement, we currently depend on global operator lookup for everything except local types. However, macro-provided operators aren't found by global operator lookup, so perform a member lookup for such cases in addition to global operator lookup. This makes macro-provided operators visible through protocol requirements they witness.
As part of SE-390, you're required to write either: - `consume self` - pass self as a `consuming` parameter to a function - `discard self` before the function ends in a context that contains a `discard self` somewhere. This prevents people from accidentally invoking the deinit due to implicit destruction of `self` before exiting the function. rdar://106099027
…thout-global-operator-lookup Eliminate macro-generated operators from global operator lookup
Implement checking for missing consume-on-all-paths of `self` in `discard`-ing contexts.
…e file The parser is currently responsible for adding local type declarations to a `SourceFile`, which IR generation later queries. However, IRGen never sees the source files associated with macro expansion buffers, so local types introduced there don't get recorded. In time, this approach of using the parser to record semantic information should be replaced with something more "pull" oriented. For now, however, record local type declarations in the outermost enclosing source file... so we see the ones produced by macro expansions, too. Fixes rdar://109370309.
…-lookup [Member name lookup] Eliminate non-lazy member loading.
Remove #ifndef on skipVarDeclAssert in SILBuilder::createAllocBox signature
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]
Can you help keep this open source service alive? 💖 Please sponsor : )