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
Merge main 2023-01-05 #5139
Merged
Merged
Merge main 2023-01-05 #5139
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
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`.
…o retrieve contextual type rdar://94224692
…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
…s on _borrow self and chain into methods.
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
[stdlib] Expose index rounding entry points
Fix two compile-time bugs
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.
…pple#62807) * Update lexicon.md * fix typo
…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
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.
No description provided.