forked from swiftlang/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-04-06 #5372
Merged
Merged
Merge main 2023-04-06 #5372
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
Hmm, I'll have a look this week
|
Prevent joining lifetimes of copies with destroyed owned lexical values if there may be deinit barriers between the final consume of the copy and the destroy of the lexical value. rdar://108014714
…dation [Build] Enable RawSyntaxValidation for SwiftSyntax PR job
Previously it was disabled because we have incomplete address lifetimes for such types, and transforming to value form in mem2reg would expose verification errors due to incompleteness. Enable this case here and fixup the lifetimes using the new lifetime completion utility.
This is something that every visit() function needs to do and these manual overloads forgot to. I tried to come up with a more general solution, but due the rather nested inheritance of SILCloner this turned out harde than expected. rdar://107984038
…description [SwiftSyntax] Adjustments because recursiveDescription is removed in favor of debugDescription
for checking duplicated results from multiple type checker solutions. e.g. protocol Proto {} struct Generic<T> { func retProto() -> some Proto } func foo() -> Generic<T1> func foo() -> Generic<T2> foo().<COMPLETION> The return type of `Geric<T1>.retProto()` and `Geric<T2>.retProto()` is different, but they both spelled 'some Proto'. So IDE consumers don't care the difference. rdar://107669173
…e-cxxstdlibshim [cxx-interop] Add missing dependency to CxxStdlib
swiftlang#65016) * [IRGen] Reject enums with inaccessible tpye metadata in layout string generation rdar://107679697 Because we are currently handling most enums in layout strings by going through the metadata, we have to ensure that the metadata is accessible from the current module and reject the enum otherwise. * Use proper mechanism to create and reference dylib in test * Fix linking * Add rpath to test dylib
Enable mem2reg of enum types
…ebcfd08f8d25d5a1551ec88 [move-only] Change the destructure through deinit error to lookup the deinit at the AST level rather than the SIL level.
…7669173 [CodeCompletion] Don't take opaque types subst map into account
[SemanticARCOpts] Don't shorten owned lexical values lifetimes through deinit barriers.
Update the scope of SILBuilder in ClosureCloner.
The best substitutions we can easily find in nested functions for captured local variables are the forwarding substitutions of the current environment. These should be fine for type-substitution purposes but do not necessarily match the generic signature of the original variable's environment, which can trip these assertions. Unfortunately, I can't think of an easy way to weaken these assertions sufficiently to cover this case. This should fix the source-compat suite regression reported in rdar://107642925.
It crashes the compiler on linux rdar://108045677
The debug_step returns true for mayReadOrWriteMemory so it has to be handled there. rdar://108043268
tests: disable IRGen/run_variadic_generics.sil to unblock CI
…65172) With the changes introduced in swiftlang#65055, the Cxx module will build even when not building the stdlib as long as `SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` was set. With the further changes in swiftlang#65122 the previous flag is not necessary, and only `SWIFT_BUILD_STDLIB_CXX_MODULE` (which defaults to `TRUE`) is necessary. However, `stdlib/public/Cxx` did rely on `StdlibOptions.cmake` to be include before it, or the functions that build the target libraries will find a half configured state. `StdlibOptions.cmake` are included in `stdlib/toolchain`, in `stdlib/` and `StandaloneOverlay.cmake`. Before swiftlang#65122 it was working just because `stdlib/toolchain` was added just before. The second changes adds dependencies on the legacy layouts and the clang headers. The legacy layouts are a dependency only added to the libraries of the stdlib core (IS_STDLIB_CORE flag). Since enabling that flag also enables a bunch other stuff, and I am not sure that Cxx should be classified as "core" anyway, I preferred to add the dependency. The clang headers are another dependency of the swiftCore, which otherwise causes problems to not find the compiler headers when building Cxx. This is necessary for builds that use a previously built compiler to compile the stdlib.
…ftlang#65051) Default system linkers on non-Darwin platforms do not support the `-framework` argument for framework linking. This change updates autolinking to not emit `-framework` into the .o _swift1_autolink_entries metadata when there is no native linker support. This is related to rdar://106578342.
[MemAccessUtils] Handle debug_step in visitAccessedAddress.
[CSSolver] Add recorded pack expansion environments to solutions
…attern-subs-assertion Remove a couple of over-eager assertions
…n-check [SE-0365] Fix issue where boolean condition before `let self` condition would prevent using implicit self
…Type() SILCloner::visitScalarPackIndexInst() was calling remapASTType() on a PackType. This was becoming a SILPackType, which would then crash in a cast<>.
…ttributes Parse compound and special names in the macro role attributes (`@freestanding` and `@attached`). This allows both compound names and initializers, e.g., `init(coding:)`. Fixes rdar://107967344.
We're seeing some flakiness in this test, but aren't sure what it's complaining about. `cmp` only says where the differencewas, but doesn't print what was different. `diff` prints what was difference so we have a chance to figure out what happened.
Those builtins always need to assume a thick metatype which is a pointer. In other words the builtins need to use the maximally abstracted type. rdar://108308786
…e_borrows @guaranteed stored values will never be added to a phi in mem2reg because any uses of store borrowed locations have to be accessed via the store borrow return address and since we ban address phis altogether we will never have input sil which necessitates this. But, the DJ-edges based algorithm for inserting phi blocks in mem2reg can insert unnecessary phis which are removed later. Ensure fixPhiPredBlock handles both owned and guaranteed stored values correctly for this reason.
… to using 'pthread' threading package (swiftlang#65329) To be able to correctly exercise Concurrency on freestanding, default to using 'pthread' threading package rdar://102259828
…roduced-names [Macros] Improve parsing, representation, and serialization of role attributes
…oner-sillyness SIL: TypeSubstCloner::remapASTType() should not call getLoweredRValueType()
…_body_diff Use diff instead of cmp in `test/InterfaceHash/edited_method_body.swift`
…TryExpr` rdar://108391690
…iling-closure-in-try [SourceKit] Expand editor placeholder to trailing closures inside a `TryExpr`
Fix mem2reg error due to multi block mem2reg with store_borrows
fix `Builtin.sizeof` et al for metatypes
Enable mem2reg and temprvalueopt on lexical enums
[Macros] Remove usages of deprecated methods in SwiftSyntaxMacros
because wasi-libc's `stdint.h` is highjacked by libcxx's `stdint.h` tries to load the next `stdint.h` and it results in loading whole `std` C++ standard library. However, loading whole std during building Swift stdlib through SwiftShims causes cyclic reference among Swift stdlib types and libc.
kateinoigakukun
force-pushed
the
katei/merge-main-2023-04-06
branch
from
April 25, 2023 01:07
5dda69d
to
023701c
Compare
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.