forked from apple/swift
-
Notifications
You must be signed in to change notification settings - Fork 28
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
[pull] swiftwasm from main #5493
Merged
Merged
Conversation
This file contains 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
…ume`-d. Pattern matching as currently implemented is consuming, but that's not necessarily what we want to be the default behavior when borrowing pattern matching is implemented. When a binding of noncopyable type is pattern-matched, require it to be annotated with the `consume` operator explicitly. That way, when we introduce borrowing pattern matching later, we have the option to make `switch x` do the right thing without subtly changing the behavior of existing code. rdar://110073984
…e scope Well, this is fun. Due to the use of the module-scope lookup table to find operators, we need to carefully filter out any macro-introduced declarations that *aren't* operators when forming the module-scope lookup table. Otherwise, we can find macro-introduced static entities within types... from completely unrelated scopes. Fixes rdar://109219036.
Operators introduced by member macros are not getting found by global operator lookup. This is technically a bug, but due to the potential cost of having to expand macros on/in types just to find operators, for now we're just going to document here that it doesn't work and reconsider the semantics.
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.
…le-scope-lookup Only inject macro-introduced operators into module scope
…re-consume Require `switch` on a noncopyable-type binding to be explicitly `consumed`.
[Clang importer] Eliminate redundant imports of C++ fields as properties
[SIL Builder] Don't try to micro-optimize away a bool parameter with NDEBUG
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 : )