Skip to content

[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 13 commits into from
Jun 5, 2023
Merged

[pull] swiftwasm from main #5495

merged 13 commits into from
Jun 5, 2023

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 5, 2023

See Commits and Changes for more details.


Created by pull[bot]

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

meg-gupta and others added 13 commits June 2, 2023 11:57
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
@kateinoigakukun kateinoigakukun merged commit 2e8c037 into swiftwasm Jun 5, 2023
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.

5 participants