Skip to content
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 9 commits into from
Jun 4, 2023
Merged

[pull] swiftwasm from main #5493

merged 9 commits into from
Jun 4, 2023

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 4, 2023

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

jckarter and others added 9 commits June 2, 2023 18:14
…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
@kateinoigakukun kateinoigakukun merged commit 358b507 into swiftwasm Jun 4, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants