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

Merge main 2023-01-05 #5139

Merged
merged 213 commits into from
Jan 7, 2023
Merged

Merge main 2023-01-05 #5139

merged 213 commits into from
Jan 7, 2023

Conversation

kateinoigakukun
Copy link
Member

No description provided.

cbjeukendrup and others added 30 commits September 23, 2022 19:27
Upstream build system zippering support.

Setting the `SWIFT_ENABLE_MACCATALYST` flag will build the compatibility
libraries with zippering enabled.

Note that AppleClang and LLVM Clang use different flags to write
zippered files. The Swift stdlib build doesn't know what clang we're
using, so we can't ask it for the compiler ID to determine which whether
we're using AppleClang or LLVM clang, hence the nasty `execute_process`
trick to figure out whether the compiler that's actually compiling the
stdlib knows about the flag or not.
Adding maccatalyst support to the osx nightly package.
In various places we need to call the Windows API, and because Swift uses UTF-8
for its string representation, we can’t call the ANSI API functions (because the
code page used for the ANSI functions varies depending on the system locale
setting). Instead, we need to use the wide character APIs.

This means that we need to convert UTF-8 to wide character and vice-versa in
various places in the runtime.

rdar://103397975
Instead of triggering a fatal error on failure, return `nullptr` and
let the caller decide what to do about it.  The CommandLine code should
trigger a fatal error, of course.

rdar://103397975
`SWIFT_RUNTIME_STDLIB_INTERNAL` does `extern "C"`, so we can't put these
in a namespace and have to use a C-style prefix instead.

Also slightly rearrange the code in `CommandLine.cpp`.

rdar://103397975
It makes sense to move this function into the new Win32 header.

rdar://103397975
They're useful functions to have; I don't think we want them to be API, but
having them as SPI is conceivably useful for other purposes, and avoids everyone
rolling their own copy.

rdar://103397975
…tements

Visiting of transformed `do` shouldn't run syntatic diagnostics because
they are going to be performed by `visit` that called `visitDoStmt`.
…syntactic elements that don't contain completion token
With AST transform enabled by default most of the previously
invalid declarations became valid (due to SE-0373 being implemented
only for AST transform).
With type-wrappers a custom attribute may reference a type and lead to a
cycle in deserialization if the target type references the type-wrapper.
To avoid this scenario, move deserializing the custom decls from before
to after the decl they are attached to.

rdar://103425758
Local discriminators for named entities are currently being set by the
parser, so entities not created by the parser (e.g., that come from
synthesized code) don't get local discriminators. Moreover, there is
no checking to ensure that every named local entity gets a local
discriminator, so some entities would incorrectly get a local
discriminator of 0.

Assign local discriminators as part of setting closure discriminators,
in response to a request asking for the local discriminator, so the
parser does not need to track this information, and all local
declarations---including synthesized ones---get local discriminators.
And add checking to make sure that every entity that needs a local
discriminator gets assigned one.

There are a few interesting cases in here:
* There was a potential mangling collision with local property
wrappers because their generated variables weren't getting local
discriminators
* $interpolation variables introduced for string interpolation weren't
getting local discriminators, they were just wrong.
* "Local rename" when dealing with captures like `[x]` was dependent on
the new delcaration of `x` *not* getting a local discriminator. There
are funny cases involving nesting where it would do the wrong thing.
The parser no longer sets local discriminators, and this function is
currently only responsible for adding local type declarations to the
source file. Rename it and remove most of the former callers so it
does just that.
The "local context" was only used to prevent parsing of closures in a
non-local context, and also string interpolations because they are
similar-ish to closures. However, this isn't something a parser should
decide, so remove this special-case semantic check from the parser and
eliminate the notion of "local context" entirely.
Instead of passing an unapplied reference to a (either static or
instance) method, let's form a thunk and use it to forward arguments
to the underlying method invocation. This way it's possible to
get a uniform type for all instance methods that always starts
with `self` type and supports `mutating` methods by marking
`self` as `inout`.
…hods

Add support for global async functions and actor-isolated methods
by determining isolation context of the method attribute is associated
with and injecting try/await when appropriate.
Resolves rdar://103531208
lorentey and others added 27 commits January 4, 2023 21:24
[stdlib] Expose index rounding entry points
Instead of bailing out, use the lowered type.

rdar://103834325
[stdlib] Export grapheme breaking facility
…rfaces

[Sema] TypeWrappers: If type wrapper comes from `.swiftinterface` use synthesized decls
A destroy_addr also involves a read from the address. It's equivalent to a `%x = load [take]` and `destroy_value %x`.
It's also a write, because the stored value is not available anymore after the destroy.

Fixes a compiler crash in SILMem2Reg.

rdar://103879105
…perands

We already ignored side effects of debug_value with non-address operands. Now also do this for address operands.
EscapeUtils: fix a wrong handling of argument indices in walkUpApplyResult
Centralise code to map between UTF-8 and UTF-16 on Windows.
…stential_extension

Improve diagnostics when trying to extend existential type
…05b732475052d170c76

[borrow-operator] Add initial support for applying _borrow to self when calling a method.
SILCombine: a better fix for optimizing keypath-offset-of
Get the compiler building again on 32-bit architectures
…terator-op

[cxx-interop] Instantiate templated `operator==` for iterator types
…ime-metadata-entry

[IRGen] RuntimeMetadata: Reference type descriptors indirectly when required
[Compile Time Constant Extraction] Add extraction of Dictionary values.
ComputeSideEffects: correct side effects for destroy_addr
…ule imports

This changes the scanner's behavior to "resolve" a discovered module's dependencies to a set of Module IDs: module name + module kind (swift textual, swift binary, clang, etc.).

The 'ModuleDependencyInfo' objects that are stored in the dependency scanner's cache now carry a set of kind-qualified ModuleIDs for their dependencies, in addition to unqualified imported module names of their dependencies.

Previously, the scanner's internal state would cache a module dependnecy as having its own set of dependencies which were stored as names of imported modules. This led to a design where any time we needed to process the dependency downstream from its discovery (e.g. cycle detection, graph construction), we had to query the ASTContext to resolve this dependency's imports, which shouldn't be necessary. Now, upon discovery, we "resolve" a discovered dependency by executing a lookup for each of its imported module names (this operation happens regardless of this patch) and store a fully-resolved set of dependencies in the dependency module info.

Moreover, looking up a given module dependency by name (via `ASTContext`'s `getModuleDependencies`) would result in iterating over the scanner's module "loaders" and querying each for the module name. The corresponding modules would then check the scanner's cache for a respective discovered module, and if no such module is found the "loader" would search the filesystem.

This meant that in practice, we searched the filesystem on many occasions where we actually had cached the required dependency, as follows:
Suppose we had previously discovered a Clang module "foo" and cached its dependency info.
-> ASTContext.getModuleDependencies("foo")
--> (1) Swift Module "Loader" checks caches for a Swift module "foo" and doesn't find one, so it searches the filesystem for "foo" and fails to find one.
--> (2) Clang Module "Loader" checks caches for a Clang module "foo", finds one and returns it to the client.

This means that we were always searching the filesystem in (1) even if we knew that to be futile.
With this change, queries to `ASTContext`'s `getModuleDependencies` will always check all the caches first, and only delegate to the scanner "loaders" if no cached dependency is found. The loaders are then no longer in the business of checking the cached contents.

To handle cases in the scanner where we must only lookup either a Swift-only module or a Clang-only module, this patch splits 'getModuleDependencies' into an alrady-existing 'getSwiftModuleDependencies' and a newly-added 'getClangModuleDependencies'.
[stdlib] String.UTF8View.index(_:offsetBy:limitedBy:): mark encoding of result
Add error checks for input to -package-name
Resolves rdar://103531208
[test] Disable test/stdlib/StringIndex.swift to unblock CI
…solution

[Dependency Scanning] Refactor the scanner to resolve unqualified module imports
@kateinoigakukun kateinoigakukun marked this pull request as ready for review January 7, 2023 05:18
@kateinoigakukun kateinoigakukun merged commit 1bb78dc into swiftwasm Jan 7, 2023
@kateinoigakukun kateinoigakukun deleted the katei/merge-main-2023-01-05 branch January 7, 2023 05:19
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