profile
viewpoint

apple/swift 53945

The Swift Programming Language

serviceslabs/SugarRecord 0

CoreData/Realm sweet wrapper written in Swift

zoecarver/airplay-server 0

A low level AirPlay server

zoecarver/AudioKit 0

Swift audio synthesis, processing, & analysis platform for iOS, macOS and tvOS

zoecarver/babel-handbook 0

:blue_book: A guided handbook on how to use Babel and how to create plugins for Babel.

zoecarver/babylon 0

:page_with_curl: A JavaScript parser

push eventzoecarver/swift

Varun Gandhi

commit sha be109b72a576799a018dba368c8495d5a9f0d6e7

[AST] Add method to check if a function type has a non-trivial Clang type.

view details

Meghana Gupta

commit sha 7cea31ba3c055ca316b344b3ca8eff8f35a5baa1

SILMem2Reg: Don't add dead values as phi arguments A dealloc_stack ends the lifetime of an alloc_stack on a path. We don't have to pass RunningVal beyond the dealloc_stack as phi argument to the post dominating block.

view details

Meghana Gupta

commit sha eff6b66906f094026afe1a61dae44d4eeba2709b

Add hasOwnership assertion in SILBuilder while creating unchecked_value_cast

view details

Mike Ash

commit sha b1633fdc361c847d0d22fa2ca1a674bad480200e

[Test] Remove `as AnyObject` cast from OS_objects.swift. This workaround is no longer needed. rdar://problem/27526994

view details

Mike Ash

commit sha 17e31d89d2491708aaaab2fd535c229327c979c1

[Runtime] Restore objc_addLoadImageFunc in ImageInspectionMacho.cpp. The conditional use of objc_addLoadImageFunc was accidentally removed in b5759c9fd93ea9d09613c018c48217e7e03f30bd. Put it back. rdar://problem/70452221

view details

Doug Gregor

commit sha 6a40a3a8aac7b4133bac70f98d92adabf30b6f7b

[SE-0289] Add support for @resultBuilder. "Function builders" are being renamed to "result builders". Add the corresponding `@resultBuilder` attribute, with `@_functionBuilder` as an alias for it, Update test cases to use @resultBuilder.

view details

Varun Gandhi

commit sha a3fc337d01228347a95c6bb7004d99b426ec80b5

[CMake] Compile with library evolution for all Darwin platforms. In practice, SWIFT_HOST_VARIANT_SDK may be IOS or some other non-OSX Darwin platform. Fixes part of rdar://70156840.

view details

Varun Gandhi

commit sha dd4a9f3bde5c960e9b35bb662698cfe8d5c0a730

[CMake] Enable library evolution for Darwin overlay. Fixes rdar://70156840.

view details

Slava Pestov

commit sha 548b96a9ff48861a99d7251648f48e3eb8d90d25

Sema: Add documentation comments for ExportContext

view details

Slava Pestov

commit sha d579b697f6c104cf4f7469ca6b0081193c6e2347

Sema: Teach ExportContext to compute whether we're inside a deprecated declaration

view details

Slava Pestov

commit sha 78d2cf2ee945031e0113056d4ea221b3ce772ccb

Sema: Teach ExportContext to compute whether we're inside an implicit declaration

view details

Slava Pestov

commit sha 85d24953de5c14eb83e4c8492bacd2eef4869986

Sema: Teach ExportContext to compute whether we're inside an unavailable declaration

view details

Meghana Gupta

commit sha 83474707eea654d81bc49565f952c84cc19508c9

Enable SILMem2Reg for OSSA SILMem2Reg has roughly 2 central algorithms, removal of alloc_stack with uses in a single block vs multiple blocks. While replacing loads and stores to the stack location in each of the 2 algorithms, new handling of qualifiers like [assign], [copy] and [take] which are new to OSSA are needed. Also Disable SILMem2Reg when we see this pattern: load [take] (struct_element_addr/tuple_element_addr %ASI) Convert SILMem2Reg tests into ossa And add new SILMem2Reg tests for non-trivial values. Thanks to zoecarver for additional tests.

view details

Meghana Gupta

commit sha 0ea5d055a20e2066ba1e034d52b1dead007a4dab

Delete debug_value_addr of stack location, if a debug_value of the RunningVal is already found

view details

Meghana Gupta

commit sha 06eaf6bba4de85631c532cb9bb9cd232758706c4

Disable SILCombine of unchecked_bitwise_cast to unchecked_ref_cast in OSSA unchecked_ref_cast is a forwarding cast while unchecked_bitwise_cast is not. We cannot just convert one to other in OSSA. Disable it now.

view details

Doug Gregor

commit sha 0d568a93d46973ac29eb1d0f4311e7ffd11df485

[SE-0289] Update diagnostics & many other strings to "result builders"

view details

Doug Gregor

commit sha 6d41524fe66c21c98165a6836848736fb0aef929

[SE-0289] Finish renaming source code, tests to "result builders"

view details

Doug Gregor

commit sha b6c0145932ad121635f8413b16bef68ddf01cc38

[SE-0289] Continue printing @_functionBuilder in .swiftinterfaces. Maintain the ability for older Swift compilers to read .swiftinterfaces that make use of result builders by always emitting @_functionBuilder rather than the newer @resultBuilder.

view details

Erik Eckstein

commit sha c6be347d3ae3b56a2dc19ac04b14d2182d805284

SILCombine: fix metatype simplification Don't reuse argument metadata if it's an indirect argument. Fixes a verifier crash. https://bugs.swift.org/browse/SR-13731 rdar://problem/70338666

view details

eeckstein

commit sha 0d6e79c2d4072664a7436341cf646aceb5987ce3

Merge pull request #34375 from eeckstein/fix-metadat-combine SILCombine: fix metatype simplification

view details

push time in 3 hours

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@varungandhi-apple I've updated createConstant to check if type is associated with a clang::EnumDecl and if that enum decl's base type is _Bool then set isBool = true. I think this is more correct because there's no guarantee that the bit-width will be 1 if the base type is a boolean. What do you think?

zoecarver

comment created time in 3 hours

Pull request review commentapple/swift

[cxx-interop] Support templated constructors.

 static ConcreteDeclRef generateDeclRefForSpecializedCXXFunctionTemplate(   auto *newParamList =       ParameterList::create(ctx, SourceLoc(), newParams, SourceLoc()); +  if (isa<ConstructorDecl>(oldDecl)) {+    DeclName ctorName(ctx, DeclBaseName::createConstructor(), newParamList);+    auto newCtorDecl = ConstructorDecl::createImported(+        ctx, specialized, ctorName, oldDecl->getLoc(), /*failable=*/false,+        /*failabilityLoc=*/SourceLoc(), /*throws=*/false,+        /*throwsLoc=*/SourceLoc(), newParamList, /*genericParams=*/nullptr,+        oldDecl->getDeclContext());+    return ConcreteDeclRef(newCtorDecl);+  }+   // Generate a name for the specialized function.   std::string newNameStr;   llvm::raw_string_ostream buffer(newNameStr);

@varungandhi-apple because I added a special case for constructor decls, we don't need to use getMangledName. So, thanks for telling me to wait in #34389.

zoecarver

comment created time in 9 hours

PullRequestReviewEvent

PR opened apple/swift

Reviewers
[cxx-interop] Support templated constructors. C++ Interop

We support function templates, we support constructors. Here are a few small changes to support templated constructors.

+105 -4

0 comment

7 changed files

pr created time in 9 hours

push eventzoecarver/swift

zoecarver

commit sha d8eeb4e0fd3fe5752618aa69655a15d06cdd2ad6

[cxx-interop] Add static "createImported" member to "ConstructorDecl".

view details

zoecarver

commit sha 3ab74dbb3a79a80dc70a00942136ab6b5404a946

[cxx-interop] Support templated C++ constructors.

view details

push time in 9 hours

create barnchzoecarver/swift

branch : cxx/templated-constructors

created branch time in 9 hours

pull request commentapple/swift

Fix two issues with the SwiftGlibc module map

@scentini see my above comment. We're going to need to update those three files to get the Linux build working.

martinboehme

comment created time in 12 hours

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

It looks like I'll need to switch back to my original implementation. Sometimes a user of createConstant is trying to get a Bool type but doesn't pass an APInt with width 1.

zoecarver

comment created time in 3 days

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@swift-ci please test Windows.

zoecarver

comment created time in 3 days

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@swift-ci please test Windows.

zoecarver

comment created time in 3 days

pull request commentapple/swift-corelibs-foundation

[cxx-interop] Fix two headers to be valid in C++ mode.

Friendly ping.

zoecarver

comment created time in 3 days

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@swift-ci please smoke test and merge.

zoecarver

comment created time in 3 days

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@swift-ci please smoke test and merge.

zoecarver

comment created time in 3 days

PR closed apple/swift

Reviewers
[nfc] Make getMangledName a virtual member of ClangModuleLoader.

This will allow it to be used anywhere in the code base through an ASTContext. We should prefer using getMangledName over manually creating a mangler and mangling decls to catch special cases (such as CXXConstructorDecl).

+7 -1

2 comments

2 changed files

zoecarver

pr closed time in 3 days

pull request commentapple/swift

[nfc] Make getMangledName a virtual member of ClangModuleLoader.

I feel like I'm missing context (heh) on where this is intended to be used. Is there a further PR where you'd like to use this method? Would it make sense to have this commit be in that PR instead of it being in a standalone PR?

Yes, I have a patch to support templated constructors I'm planning to put up soon. I generally try to factor out as many NFCs as I can to make the larger changes easier to review. That being said, I don't really mind one way or another so, I'll close this and add just add it to the other PR (as you suggested).

zoecarver

comment created time in 3 days

push eventapple/swift

Zoe Carver

commit sha f0f22467931f7410bff76248806b94a9d5e64537

[cxx-interop] Support C++ function templates in Swift. (#33053) This patch adds rudimentary support for C++ template functions in swift.

view details

push time in 3 days

PR merged apple/swift

Reviewers
[cxx-interop] Support function templates. C++ Interop

This patch adds rudimentary support for C++ template functions in swift. There's still a lot lacking but, that mostly has to do with the clang type converter which can be updated with incremental follow up patches.

Unfortunately, there's some ugliness and unconventional logic in this patch. First, we have to generate and define the specialization in the SILGen phase (instead of when we import the function) so we have access to the argument types and substitution map. Similarly, in IRGen, we can't get the function pointer while visiting the function_ref instruction because we also need the substitution map to find the correct specialization of the template (this also means there may be problems when the compiler can't find the corresponding function_ref, i.e. if the function was passed as an argument).

+531 -88

71 comments

23 changed files

zoecarver

pr closed time in 3 days

push eventzoecarver/swift

zoecarver

commit sha 7f33d14ce6379530bcc8321c080b16d869074fc9

[nfc] Make getMangledName a virtual member of ClangModuleLoader. This will allow it to be used anywhere in the code base through the an ASTContext.

view details

push time in 3 days

PR opened apple/swift

[nfc] Make getMangledName a virtual member of ClangModuleLoader.

This will allow it to be used anywhere in the code base through an ASTContext. We should prefer using getMangledName over manually creating a mangler and mangling decls to catch special cases (such as CXXConstructorDecl).

+6 -1

0 comment

2 changed files

pr created time in 3 days

push eventzoecarver/swift

zoecarver

commit sha fa35431b50c55d2114431a6440e0f8faa2b571df

[nfc] Make getMangledName a virtual member of ClangModuleLoader. This will allow it to be used anywhere in the code base through the an ASTContext.

view details

push time in 3 days

create barnchzoecarver/swift

branch : cxx/public-get-mangled-name

created branch time in 3 days

Pull request review commentapple/swift

[cxx-interop] Support bool-based enums.

 ClangImporter::Implementation::createConstant(Identifier name, DeclContext *dc,     // Create the expression node.     StringRef printedValueCopy(context.AllocateCopy(printedValue));     if (value.getKind() == clang::APValue::Int) {-      if (type->getCanonicalType()->isBool()) {+      if (type->getCanonicalType()->isBool() ||+          value.getInt().getBitWidth() == 1) {

The tests passed so I removed the first condition.

zoecarver

comment created time in 3 days

PullRequestReviewEvent

push eventzoecarver/swift

Butta

commit sha 69d04aad08da3245f87c6a2df35869126d48b55e

[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.

view details

Martin Boehme

commit sha a5e953b69009b59541420d06496206a26961a976

Add support for calling C++ constructors. Because C++ constructors always take a `this` pointer to the object to be initialized, we mark the SIL function return type with the `@out` attribute. On the IRGen side, we retrofit support for formal indirect return values as well as thin metatypes.

view details

Martin Boehme

commit sha 7ad2eef26508ad92d8d92f2d5546913c0ced3bbd

Only import constructors marked `noexcept`.

view details

Martin Boehme

commit sha 384854810a60a69c8df8a8c0248e209adc28c295

Revert "Only import constructors marked `noexcept`." This reverts commit 29650d8c1f302708a32304d49c703c9ddbf30b75. As discussed here, we want to import all constructors (whether they are marked `noexcept` or not) as non-throwing initializers; https://forums.swift.org/t/handling-c-exceptions/34823/50

view details

Martin Boehme

commit sha fd00bc1f01357ecd264b8216373c23014771c124

Move tests from `CXXInterop` to `Interop/Cxx`. This is the canonical location that we've agreed on.

view details

Martin Boehme

commit sha e6067275a6659cfab8640e68e93a5bba36ddca20

Duplicate changes to GenClangType in ClangTypeConverter. See discussion here: https://github.com/apple/swift/pull/30630#discussion_r398967412

view details

Martin Boehme

commit sha b2c5a3eeed4e0d80c819f98c816481fbedc49526

Add a constructor thunk if required to add additional constructor arguments. Also add more IR tests and make various other changes.

view details

Martin Boehme

commit sha 3066e16c37e26a5fea370877409b4d0bd1c0fea6

Remove redundant "cxx" from test names.

view details

Martin Boehme

commit sha 5644137ea0696164c5b5835179b1ec450d508c88

Eliminate duplication of code for adding empty argument names.

view details

Martin Boehme

commit sha bed26039446c189a82c453126e0a622e43c6256d

Various changes after merging master: - Adapt tests to changes that have happened in the meantime (e.g. `HasVirtualBase` is rightly no longer considered loadable) - Don't import copy or move constructors (noticed this because references are now imported correctly, so copy and move constructors suddenly started showing up in the SIL test) - Don't try to define an implicitly-deleted default constructor (this previously broke loadable-types-silgen.swift)

view details

Martin Boehme

commit sha beaaa742c3e774b6739de26bb1a3f0c8761512a5

Don't put an `sret` attribute on the `this` argument.

view details

Martin Boehme

commit sha 8416ccfa06d05da67af70a8ed57a2f120ea251b2

Rename constructors-ir.swift to constructors-irgen.swift.

view details

Martin Boehme

commit sha 8f6042aa0870a527505262c7dbe89ec7ffe20e12

Add additional IR tests for a class without a virtual base class.

view details

Martin Boehme

commit sha c9405fb7fc338f59db4386488245a3ce82227e00

Add Windows-name-mangled version of symbol to SIL test.

view details

Martin Boehme

commit sha cb4ddda6e2292c584cb83905f3f9df17a4e017f1

Avoid crashing if lldb imports C++ structs without enabling C++ interop.

view details

Martin Boehme

commit sha 33e8c717f2682b913eb04e1c7746c84315be90ef

Update comment in VisitCXXRecordDecl().

view details

Martin Boehme

commit sha 7e8ea120701b33958a1adca9e885a99f5d583607

Respond to review comments.

view details

Martin Boehme

commit sha 1ce3753d08522cefe255f4acf498dba5085aa60a

Another response to review comments.

view details

Martin Boehme

commit sha faca489c6f524096019fd124cba847949972e0db

Add a test that Objective-C types passed to a C++ constructor are bridged correctly.

view details

Martin Boehme

commit sha 83b51b95b534108494de1032bb4e098274fe606b

Add SILGen and IRGen tests for passing Objective-C types to C++ constructors.

view details

push time in 3 days

pull request commentapple/swift

[cxx-interop] Support function templates.

@swift-ci please test Windows platform.

zoecarver

comment created time in 3 days

pull request commentapple/swift

[cxx-interop] Support function templates.

@swift-ci please test windows platform.

zoecarver

comment created time in 3 days

Pull request review commentapple/swift

[cxx-interop] Support bool-based enums.

 ClangImporter::Implementation::createConstant(Identifier name, DeclContext *dc,     // Create the expression node.     StringRef printedValueCopy(context.AllocateCopy(printedValue));     if (value.getKind() == clang::APValue::Int) {-      if (type->getCanonicalType()->isBool()) {+      if (type->getCanonicalType()->isBool() ||+          value.getInt().getBitWidth() == 1) {

Because this is a more general API (not just used for enums) I wasn't sure if all users would pass it an APInt where bitwidth = 1. I'll try removing the check and see if the tests still all pass.

zoecarver

comment created time in 3 days

PullRequestReviewEvent

pull request commentapple/swift

[cxx-interop] Support function templates.

@swift-ci please test.

zoecarver

comment created time in 3 days

push eventzoecarver/swift

zoecarver

commit sha b2b6b05bc5721c160fdcc187c0cbd713360b65b2

[cxx-interop] Support C++ function templates in Swift. This patch adds rudimentary support for C++ template functions in swift.

view details

push time in 3 days

pull request commentapple/swift

[cxx-interop] Support function templates.

@swift-ci please test and merge.

zoecarver

comment created time in 4 days

Pull request review commentapple/swift

[cxx-interop] Support function templates.

 ImportedType ClangImporter::Implementation::importFunctionReturnType(                     OptionalityOfReturn); } +static Type+findGenericTypeInGenericDecls(const clang::TemplateTypeParmType *templateParam,+                              ArrayRef<GenericTypeParamDecl *> genericParams) {+  StringRef name = templateParam->getIdentifier()->getName();+  auto genericParamIter =+      llvm::find_if(genericParams, [name](GenericTypeParamDecl *generic) {+        return generic->getName().str() == name;+      });+  // TODO: once we support generics in class types, replace this with

@hlopko Just FYI, I think #33284 will start crashing once this lands. Happy to help resolve the issues if you'd like.

zoecarver

comment created time in 4 days

PullRequestReviewEvent

pull request commentapple/swift

[cxx-interop] Support function templates.

@swift-ci please test and merge.

zoecarver

comment created time in 4 days

push eventzoecarver/swift

zoecarver

commit sha c919f69fc4328a2f8af602800378ad5c98b72d10

[cxx-interop] Support C++ function templates in Swift. This patch adds rudimentary support for C++ template functions in swift.

view details

push time in 4 days

pull request commentapple/swift

[cxx-interop] Support function templates.

There are some small changes (and lots of tests) that need to be made to support templated constructors. I'm going to implement that in a follow-up patch.

zoecarver

comment created time in 4 days

push eventzoecarver/swift

Mike Ash

commit sha ece0399d601eec1069131f465bdbe7e16f4c6a50

[Runtime] Have ConcurrentReadableHashMap use 1-byte or 2-byte indices when possible.

view details

Butta

commit sha 69d04aad08da3245f87c6a2df35869126d48b55e

[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.

view details

Alexey Komnin

commit sha 4fa17bf59774ae6543a33b1a29f01320705f4dfe

SR-12022: refactor LiteralExpr to combine common initializer code

view details

Doug Gregor

commit sha e36011def493dceec79381f2e4a051f1f1e610fe

[Type checker] Delay the diagnosis of missing witnesses further. The handling of "global" missing witnesses would diagnose a missing witness (showing "almost" matches) and then, later, provide the Fix-It to add the declaration if the user wants it. Delay the diagnostic part until later, when we add the missing witness. While here, correct an existing issue with memory corruption that occurs because we would diagnose some of these witnesses, then clear a "global" witness list, while still iterating through parts of that list.

view details

Doug Gregor

commit sha fe4a8bb9f926684d2621fba13cc326580380bcbc

[Clang importer] Allow both sync and async imports with the same name. The Clang importer was filtering out cases where the same declaration is imported twice under the same name, which can now happen when one is synchronous and one is asynchronous. This happens when, e.g., an Objective-C class provides both a completion-hander-based asynchronous version and a synchronous version, and the Swift names line up after the completion-handler parameter is dropped. Stop filtering these out. Overload resolution is capable of handling synchronous/asynchronous overloading based on context.

view details

Doug Gregor

commit sha 50f870566a1a35b4073adb1bce078451790b74a5

Handle conformance with multiple protocol requirements with the same selector. When concurrency is enabled, the same Objective-C method on a protocol can be imported as two different protocol requirements, both of which have the same selector. When performing conformance checking, only treat a given @objc protocol requirement as "unsatisfied" by a conformance if none of the requirements with the same Objective-C selector (+ instance/class designation) are satisfied.

view details

Doug Gregor

commit sha 591e6e89e259818a8dd56bbba41057e776d92c8a

[Concurrency] Only infer @asyncHandler for witnesses within actor classes. Actor classes are by definition new code, so only perform inference of @asyncHandler from a protocol requirement to witnesses when those witnesses are within an actor class. This is partly because @asyncHandler might not have reasonable semantics outside of actor classes anywhere (where would you execute the detached task?), and partly because it is a source-compatibility problem due to the combination of... 1) Inferring @asyncHandler on imported Objective-C protocol methods for existing protocols, 2) Inferring @asyncHandler from those protocol methods to an existing method in a class that conforms to that protocol, and 3) Using an API that is now overloaded for both synchronous and asynchronous callers will end up preferring the asynchronous version, then fail due to a missing "await". The individual steps here are all reasonable, but the result is a source break, so back off on @asyncHandler inference for witnesses outside of actor classes. New code gets the more-asynchronous behavior for free.

view details

Doug Gregor

commit sha bb066b6fa68f06885c84838be7f7e264d70bc0e6

[Concurrency] Make actor-isolated protocol witnesses an error. With actor isolation checking for protocol witnesses moved out of the witness-matching phase, move the corresponding diagnostics from notes (that would have been on the "type does not conform" error) to freestanding errors.

view details

Simon Evans

commit sha 960d0e30ee2b70ba3bb7ec076c16045afab01589

Linux: Fix -static-executable and remove swiftImageInspectionShared - Remove references to swiftImageInspectionShared on Linux and dont have split libraries between static/non-static linked executables. - -static-executable now links correctly Linux. Note: swift::lookupSymbol() will not work on statically linked executables but this can be worked around by using the https://github.com/swift-server/swift-backtrace package.

view details

Cassie Jones

commit sha 8ffaf79ec2e106a58dff2402a06210bf9ca97357

[build] Support installing swift-driver without swiftpm The install-swift-driver phase knows how to build swift-driver using CMake. Allowing only install-swift-driver without plain swift-driver allows installing it without requiring swiftpm.

view details

Michael Gottesman

commit sha e7761cf997897aaa38af0d0969ca9acd7e504fbf

[DebuggingTheCompiler] Document a few flags for dumping llvm-ir. I needed to use these and realized they were not documented here. I had them in my brain, but others may not, so seemed good to do.

view details

Xi Ge

commit sha 00eb2e9db2140d7a7acdd9aa3176e12df9012a7d

Frontend: add a frontend flag to disable building module from textual interface This is for testing purposes to ensure prebuilt modules are up to date. rdar://68770805

view details

Cassie Jones

commit sha 20995ae0bbf765d39cb28c63318e301c27cc2157

[build] Add FILES_MATCHING to CMakeLists.txt The bare "PATTERN" argument by default does nothing, you need either "EXCLUDE" or "FILES_MATCHING" to make it do something. This likely wasn't previously a problem because clang is only installing headers, but it should be fixed for robustness.

view details

Robert Widmann

commit sha 82e9935885bed95b0091476bfda95f4fdae14e9b

Correct the Serialization of Embedded Swift Dependencies llvm-bcanalyzer does *not* like it when there are multiple block info metadata blocks in the same bitstream file. This patch will skip the emission of that and just jump straight to the metadata block when we're not reading a "standalone" incremental dependency file. While I'm here, also add the right block abbreviation info so we can get a decent dump from llvm-bcanalyzer

view details

Robert Widmann

commit sha d7cd605c3129bd567f5be18b57eec33135dc439e

Adjust the Registration of the Pseudo-Job for External Incremental Dependencies Register the module the external dependencies ride in with the pseudo-job in the Driver. This is a hack.

view details

Robert Widmann

commit sha a77f059c8292c157f07a4de9a2d1ee9597c5b57d

Turn on Cross-Module Incremental Dependencies! Cross-Module incremental dependencies are a new experimental mode of the Swift driver and frontend. Through a tight partnership between the two, we enable the driver to have far greater visibility into the dependency structure of a Swift module. Rather than invent a new model, we have chosen to extend the existing incremental compilation model that works for a single module to multiple modules. To do this, we need the frontend to emit Swift dependencies in a form the driver can consume. We could emit these metadata in the form of an extra supplementary output that summarizes the contents of a generated module. However, this approach comes with a number of downsides: - It requires additional integration with the build system - It assumes swiftmodule files will be consumed directly from the build directory; they are not - It incorrectly assumes a swiftmodule has but one interface. Taken in aggregate, a swiftmodule directory has one interface *per triple* Given this, the approach we take here is to encode these dependencies directly into the swiftmodule file itself. When frontends load these souped-up incremental swiftmodule files, they record in their own swiftdeps files that they depend on an incremental swiftmodule. Upon the next build, the driver is then able to read that module file, extract the swiftdeps information from it, and use it to influence the way it schedules jobs. The sum total is that we neatly extend the intra-module case of incremental builds to the inter-module case by treating swiftmodule inputs not as opaque entities, but as "big ol' flat Swift files" that just export an interface like any other Swift file within the module. As a further optimization, and because clients literally cannot observe this aspect of the incremental build, we only serialize the provides (the "defs" side of a "use-def" edge) when emitting swiftdeps metadata into swiftmodule files. rdar://69595010

view details

Doug Gregor

commit sha 147f9e6c90f66068f567b5b7a14e7eb7abdafa29

Generalize test

view details

Pavel Yaskevich

commit sha f26bce350d41ec1ffefa8cae61f759985244b055

[Sema] NFC: Move `ContextualTypePurpose` to constraint system header

view details

Pavel Yaskevich

commit sha 588d42c56440db5e6166c1e979c13c8ae3343a60

[Sema] NFC: Move `FreeTypeVariableBinding` to constraint system header

view details

Meghana Gupta

commit sha 141b032e7c6ad24133905b35a6080f872feb7dac

Enable --build-sil-debugging-stdlib for all of swift/stdlib/public (#34197) Previously it was enable only for swift/stdlib/public/core

view details

push time in 4 days

push eventzoecarver/swift

Mike Ash

commit sha ece0399d601eec1069131f465bdbe7e16f4c6a50

[Runtime] Have ConcurrentReadableHashMap use 1-byte or 2-byte indices when possible.

view details

Butta

commit sha 69d04aad08da3245f87c6a2df35869126d48b55e

[linux] remove absolute rpath of /usr/lib/swift/linux added to many shared libraries This was presumably added as a backup, in case the libraries in a toolchain couldn't be found, but will not work well, so take it out.

view details

Alexey Komnin

commit sha 4fa17bf59774ae6543a33b1a29f01320705f4dfe

SR-12022: refactor LiteralExpr to combine common initializer code

view details

Doug Gregor

commit sha e36011def493dceec79381f2e4a051f1f1e610fe

[Type checker] Delay the diagnosis of missing witnesses further. The handling of "global" missing witnesses would diagnose a missing witness (showing "almost" matches) and then, later, provide the Fix-It to add the declaration if the user wants it. Delay the diagnostic part until later, when we add the missing witness. While here, correct an existing issue with memory corruption that occurs because we would diagnose some of these witnesses, then clear a "global" witness list, while still iterating through parts of that list.

view details

Doug Gregor

commit sha fe4a8bb9f926684d2621fba13cc326580380bcbc

[Clang importer] Allow both sync and async imports with the same name. The Clang importer was filtering out cases where the same declaration is imported twice under the same name, which can now happen when one is synchronous and one is asynchronous. This happens when, e.g., an Objective-C class provides both a completion-hander-based asynchronous version and a synchronous version, and the Swift names line up after the completion-handler parameter is dropped. Stop filtering these out. Overload resolution is capable of handling synchronous/asynchronous overloading based on context.

view details

Doug Gregor

commit sha 50f870566a1a35b4073adb1bce078451790b74a5

Handle conformance with multiple protocol requirements with the same selector. When concurrency is enabled, the same Objective-C method on a protocol can be imported as two different protocol requirements, both of which have the same selector. When performing conformance checking, only treat a given @objc protocol requirement as "unsatisfied" by a conformance if none of the requirements with the same Objective-C selector (+ instance/class designation) are satisfied.

view details

Doug Gregor

commit sha 591e6e89e259818a8dd56bbba41057e776d92c8a

[Concurrency] Only infer @asyncHandler for witnesses within actor classes. Actor classes are by definition new code, so only perform inference of @asyncHandler from a protocol requirement to witnesses when those witnesses are within an actor class. This is partly because @asyncHandler might not have reasonable semantics outside of actor classes anywhere (where would you execute the detached task?), and partly because it is a source-compatibility problem due to the combination of... 1) Inferring @asyncHandler on imported Objective-C protocol methods for existing protocols, 2) Inferring @asyncHandler from those protocol methods to an existing method in a class that conforms to that protocol, and 3) Using an API that is now overloaded for both synchronous and asynchronous callers will end up preferring the asynchronous version, then fail due to a missing "await". The individual steps here are all reasonable, but the result is a source break, so back off on @asyncHandler inference for witnesses outside of actor classes. New code gets the more-asynchronous behavior for free.

view details

Doug Gregor

commit sha bb066b6fa68f06885c84838be7f7e264d70bc0e6

[Concurrency] Make actor-isolated protocol witnesses an error. With actor isolation checking for protocol witnesses moved out of the witness-matching phase, move the corresponding diagnostics from notes (that would have been on the "type does not conform" error) to freestanding errors.

view details

Simon Evans

commit sha 960d0e30ee2b70ba3bb7ec076c16045afab01589

Linux: Fix -static-executable and remove swiftImageInspectionShared - Remove references to swiftImageInspectionShared on Linux and dont have split libraries between static/non-static linked executables. - -static-executable now links correctly Linux. Note: swift::lookupSymbol() will not work on statically linked executables but this can be worked around by using the https://github.com/swift-server/swift-backtrace package.

view details

Cassie Jones

commit sha 8ffaf79ec2e106a58dff2402a06210bf9ca97357

[build] Support installing swift-driver without swiftpm The install-swift-driver phase knows how to build swift-driver using CMake. Allowing only install-swift-driver without plain swift-driver allows installing it without requiring swiftpm.

view details

Michael Gottesman

commit sha e7761cf997897aaa38af0d0969ca9acd7e504fbf

[DebuggingTheCompiler] Document a few flags for dumping llvm-ir. I needed to use these and realized they were not documented here. I had them in my brain, but others may not, so seemed good to do.

view details

Xi Ge

commit sha 00eb2e9db2140d7a7acdd9aa3176e12df9012a7d

Frontend: add a frontend flag to disable building module from textual interface This is for testing purposes to ensure prebuilt modules are up to date. rdar://68770805

view details

Cassie Jones

commit sha 20995ae0bbf765d39cb28c63318e301c27cc2157

[build] Add FILES_MATCHING to CMakeLists.txt The bare "PATTERN" argument by default does nothing, you need either "EXCLUDE" or "FILES_MATCHING" to make it do something. This likely wasn't previously a problem because clang is only installing headers, but it should be fixed for robustness.

view details

Robert Widmann

commit sha 82e9935885bed95b0091476bfda95f4fdae14e9b

Correct the Serialization of Embedded Swift Dependencies llvm-bcanalyzer does *not* like it when there are multiple block info metadata blocks in the same bitstream file. This patch will skip the emission of that and just jump straight to the metadata block when we're not reading a "standalone" incremental dependency file. While I'm here, also add the right block abbreviation info so we can get a decent dump from llvm-bcanalyzer

view details

Robert Widmann

commit sha d7cd605c3129bd567f5be18b57eec33135dc439e

Adjust the Registration of the Pseudo-Job for External Incremental Dependencies Register the module the external dependencies ride in with the pseudo-job in the Driver. This is a hack.

view details

Robert Widmann

commit sha a77f059c8292c157f07a4de9a2d1ee9597c5b57d

Turn on Cross-Module Incremental Dependencies! Cross-Module incremental dependencies are a new experimental mode of the Swift driver and frontend. Through a tight partnership between the two, we enable the driver to have far greater visibility into the dependency structure of a Swift module. Rather than invent a new model, we have chosen to extend the existing incremental compilation model that works for a single module to multiple modules. To do this, we need the frontend to emit Swift dependencies in a form the driver can consume. We could emit these metadata in the form of an extra supplementary output that summarizes the contents of a generated module. However, this approach comes with a number of downsides: - It requires additional integration with the build system - It assumes swiftmodule files will be consumed directly from the build directory; they are not - It incorrectly assumes a swiftmodule has but one interface. Taken in aggregate, a swiftmodule directory has one interface *per triple* Given this, the approach we take here is to encode these dependencies directly into the swiftmodule file itself. When frontends load these souped-up incremental swiftmodule files, they record in their own swiftdeps files that they depend on an incremental swiftmodule. Upon the next build, the driver is then able to read that module file, extract the swiftdeps information from it, and use it to influence the way it schedules jobs. The sum total is that we neatly extend the intra-module case of incremental builds to the inter-module case by treating swiftmodule inputs not as opaque entities, but as "big ol' flat Swift files" that just export an interface like any other Swift file within the module. As a further optimization, and because clients literally cannot observe this aspect of the incremental build, we only serialize the provides (the "defs" side of a "use-def" edge) when emitting swiftdeps metadata into swiftmodule files. rdar://69595010

view details

Doug Gregor

commit sha 147f9e6c90f66068f567b5b7a14e7eb7abdafa29

Generalize test

view details

Pavel Yaskevich

commit sha f26bce350d41ec1ffefa8cae61f759985244b055

[Sema] NFC: Move `ContextualTypePurpose` to constraint system header

view details

Pavel Yaskevich

commit sha 588d42c56440db5e6166c1e979c13c8ae3343a60

[Sema] NFC: Move `FreeTypeVariableBinding` to constraint system header

view details

Meghana Gupta

commit sha 141b032e7c6ad24133905b35a6080f872feb7dac

Enable --build-sil-debugging-stdlib for all of swift/stdlib/public (#34197) Previously it was enable only for swift/stdlib/public/core

view details

push time in 4 days

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

@swift-ci please smoke test.

zoecarver

comment created time in 5 days

PR opened apple/swift

Reviewers
[cxx-interop] Support bool-based enums.

This is a small fix to prevent a crash. This change simply adds another condition for the bool branch that checks if the APInt has a bit-width of 1.

There are some big changes we should make in the future around enums. But, this patch is only to prevent a crash.

+52 -2

0 comment

4 changed files

pr created time in 5 days

create barnchzoecarver/swift

branch : cxx/bool-enum

created branch time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test and merge.

martinboehme

comment created time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test and merge.

martinboehme

comment created time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

Actually, thinking about it, that won't work because even if it does correctly merge the branches before benchmarking, the benchmark will be shown as "added" so, we won't be able to get any real data from it.

martinboehme

comment created time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

https://github.com/apple/swift/pull/32721 @swift-ci please benchmark.

martinboehme

comment created time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

Thanks, @rjmccall. Given that you've both approved this PR, I'm going to go ahead and land it now.

Before it lands, I want to run the benchmarks, though. As much to test #32721 as anything else. Hopefully, this swift-ci incantation will work.

martinboehme

comment created time in 5 days

create barnchzoecarver/swift

branch : main

created branch time in 5 days

pull request commentapple/swift

[cxx-interop] Instantiate C++ templates from Swift

Here's a test case that crashes:

template<class...>
class Foo;

template<>
class Foo<> {
  enum Maybe { No, Yes };
};

But, I think it would be fair to fix that in another patch.

hlopko

comment created time in 5 days

create barnchzoecarver/swift

branch : cxx/mono-branch-swift-in-comp

created branch time in 5 days

pull request commentapple/swift

Add support for calling C++ constructors

Unless anyone has an objection, I'm going to land this patch on Wednesday.

martinboehme

comment created time in 6 days

pull request commentapple/swift

[cxx-interop] Support function templates.

Unless anyone has an objection, I'm going to land this patch on Tuesday.

zoecarver

comment created time in 6 days

pull request commentapple/swift

Add support for calling C++ constructors

@rjmccall thank you again for the help reviewing. I really appreciate your insights. Any other comments?

Hoping to land this in the next few days.

martinboehme

comment created time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 9 days

push eventmartinboehme/swift

zoecarver

commit sha 545b44e9c14f7423ec1c881c1450b8b3a568bf75

[cxx-interop] Look through template decl to find constructor when importing the function name. Sometimes, on windows, we get a function template wrapping the constructor decl. In this case, look through the function template to find the constructor decl.

view details

push time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

Yeah, that didn't work. I'll try my other idea.

martinboehme

comment created time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

https://github.com/apple/swift/pull/33053 @swift-ci please test Windows platform

martinboehme

comment created time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

It looks like (on Windows only?) it's possible for a function template to have a CXXConstructorName if it wraps a CXXConstructorDecl. I wonder if #33053 will fix this (I doubt it). But, if that doesn't work, I think a fairly simple fix would be to just get the constructor decl out of the function template if we find a function template in that branch.

martinboehme

comment created time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 9 days

push eventmartinboehme/swift

zoecarver

commit sha b0dbeff126dc8197be2fd908271cffaf96135033

[NO-MERGE] Add temporary debug info around non-constructor decl. If we get a decl that has the "CXXConstructorName" name kind but *isn't* a constructor decl, print out some debug info. This is a temporary commit to figure out what's going on with Windows.

view details

push time in 9 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 9 days

pull request commentgoogle/souper

Move insert point after PHI nodes.

thanks for the bugfix!

Of course. Thanks (both of you) for reviewing/merging!

zoecarver

comment created time in 9 days

Pull request review commentapple/swift

Update function type mangling to use Clang type when applicable.

 class ASTMangler : public Mangler {                       const ValueDecl *forDecl = nullptr);   void appendFunctionType(AnyFunctionType *fn, bool isAutoClosure = false,                           const ValueDecl *forDecl = nullptr);+  void appendClangType(AnyFunctionType *fn);+  template <typename FnType>+  void appendClangType(FnType *fn, llvm::raw_svector_ostream &os);

That's fair. I think you can use Mod->getASTContext(), but I don't feel strongly. If you'd rather the template is OK with me.

varungandhi-apple

comment created time in 9 days

PullRequestReviewEvent

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

Dropped 702689480ae3a9b018ceba5f5cca7de22ee54c3c. I'm going to double-check that this crashes before I launch into debugging it.

martinboehme

comment created time in 10 days

push eventmartinboehme/swift

zoecarver

commit sha 20222bb2ad2cb09778ee110cc80b3a2b945e9fdd

[cxx-interop] Bail if trying to convert call result to void. Don't try to coerce the result of a call to void. If the "expected" result type is void, just bail.

view details

zoecarver

commit sha b2bb47dee5330234c8eb2fb2d0a41d67949831ec

[cxx-interop] Fix Windows tests for non-trivial C++ types. * Replace `??1` with `??0` prefix in SILGen tests. * Replace `call void <constructor>` with `call {{.*}} <constructor>` because Windows ABI sometimes returns a pointer from the constructor for non-trivial types. * Make `noalias` an optional check.

view details

zoecarver

commit sha 1d3b051151adee97b51408159f8205e9f28fcb9d

[cxx-interop] Remove logic around applying attributes. Removes the logic around applying attributes to C++ constructor's indirect results. Also fixes some commenting.

view details

zoecarver

commit sha d9acaf353e5a25a4b5c01c46702407925ab5e2c7

[cxx-interop] Merge synthesized initializer tests into "constructors-silgen". We no longer synthesize initializers for C++ types so this name no longer makes sense.

view details

push time in 10 days

Pull request review commentapple/swift

Add support for calling C++ constructors

 llvm::Function *IRGenModule::getAddrOfSILFunction(   if (auto clangDecl = f->getClangDecl()) {     auto globalDecl = getClangGlobalDeclForFunction(clangDecl);     clangAddr = getAddrOfClangGlobalDecl(globalDecl, forDefinition);++    if (auto ctor = dyn_cast<clang::CXXConstructorDecl>(clangDecl)) {+      clangAddr =+          emitCXXConstructorThunkIfNeeded(*this, f, ctor, entity, clangAddr);

I agree, at least for now. Maybe in the future. I think it would be doable.

martinboehme

comment created time in 10 days

PullRequestReviewEvent

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

push eventmartinboehme/swift

zoecarver

commit sha 1c6755d96769dd9d55f9aefd061ae655ae2064f4

[cxx-interop] Remove logic around applying attributes. Removes the logic around applying attributes to C++ constructor's indirect results. Also fixes some commenting.

view details

zoecarver

commit sha 4c6f93fabc88720abbb1f5a4128f889d31b03fd7

[cxx-interop] Merge synthesized initializer tests into "constructors-silgen". We no longer synthesize initializers for C++ types so this name no longer makes sense.

view details

push time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows.

martinboehme

comment created time in 10 days

pull request commentapple/swift

Add support for calling C++ constructors

@swift-ci please test Windows platform.

martinboehme

comment created time in 10 days

push eventmartinboehme/swift

zoecarver

commit sha b2f75e46250b62b95d5799ada944abd300a2ade1

[cxx-interop] Remove logic around applying attributes. Removes the logic around applying attributes to C++ constructor's indirect results. Also fixes some commenting.

view details

zoecarver

commit sha 5cfcb00b5145d3c1db4d01f20973d28d507a7ed0

[cxx-interop] Merge synthesized initializer tests into "constructors-silgen". We no longer synthesize initializers for C++ types so this name no longer makes sense.

view details

push time in 10 days

Pull request review commentapple/swift

Add support for calling C++ constructors

 // RUN: %target-swift-frontend -I %S/Inputs -enable-cxx-interop -emit-silgen %s | %FileCheck %s  import SynthesizedInitializers+import Constructors

I'm going to merge this test with constructors-silgen. It doesn't make sense to have a "synthesized initializers" test when we never actually synthesize an initializer.

martinboehme

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentapple/swift

Add support for calling C++ constructors

+// Target-specific tests for C++ constructor call code generation.++// RUN: %swift -module-name Swift -target x86_64-apple-macosx10.9 -dump-clang-diagnostics -I %S/Inputs -enable-cxx-interop -emit-ir %s -parse-stdlib -parse-as-library -disable-legacy-type-info | %FileCheck %s -check-prefix=ITANIUM_X64+// RUN: %swift -module-name Swift -target armv7-none-linux-androideabi -dump-clang-diagnostics -I %S/Inputs -enable-cxx-interop -emit-ir %s -parse-stdlib -parse-as-library -disable-legacy-type-info | %FileCheck %s -check-prefix=ITANIUM_ARM+// RUN: %swift -module-name Swift -target x86_64-unknown-windows-msvc -dump-clang-diagnostics -I %S/Inputs -enable-cxx-interop -emit-ir %s -parse-stdlib -parse-as-library -disable-legacy-type-info | %FileCheck %s -check-prefix=MICROSOFT_X64++import Constructors+import TypeClassification++typealias Void = ()+struct UnsafePointer<T> { }+struct UnsafeMutablePointer<T> { }++public func createHasVirtualBase() -> HasVirtualBase {

SGTM.

martinboehme

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentapple/swift

Add support for calling C++ constructors

 llvm::Function *IRGenModule::getAddrOfSILFunction(   if (auto clangDecl = f->getClangDecl()) {     auto globalDecl = getClangGlobalDeclForFunction(clangDecl);     clangAddr = getAddrOfClangGlobalDecl(globalDecl, forDefinition);++    if (auto ctor = dyn_cast<clang::CXXConstructorDecl>(clangDecl)) {+      clangAddr =+          emitCXXConstructorThunkIfNeeded(*this, f, ctor, entity, clangAddr);

OK. If you want me to change something here, just let me know.

martinboehme

comment created time in 10 days

PullRequestReviewEvent

Pull request review commentapple/swift

[ownership] Enable SILMem2Reg for OSSA

 static void collectLoads(SILInstruction *I, SmallVectorImpl<LoadInst *> &Loads) static void replaceLoad(LoadInst *LI, SILValue val, AllocStackInst *ASI) {   ProjectionPath projections(val->getType());   SILValue op = LI->getOperand();+  SILBuilderWithScope builder(LI);+   while (op != ASI) {     assert(isa<UncheckedAddrCastInst>(op) || isa<StructElementAddrInst>(op) ||            isa<TupleElementAddrInst>(op));     auto *Inst = cast<SingleValueInstruction>(op);     projections.push_back(Projection(Inst));     op = Inst->getOperand(0);   }-  SILBuilder builder(LI);++  SmallVector<SILValue, 4> borrowedVals;   for (auto iter = projections.rbegin(); iter != projections.rend(); ++iter) {     const Projection &projection = *iter;+    assert(projection.getKind() == ProjectionKind::BitwiseCast ||+           projection.getKind() == ProjectionKind::Struct ||+           projection.getKind() == ProjectionKind::Tuple);++    // struct_extract and tuple_extract expect guaranteed operand ownership+    // non-trivial RunningVal is owned. Insert borrow operation to convert+    if (projection.getKind() == ProjectionKind::Struct ||+        projection.getKind() == ProjectionKind::Tuple) {+      SILValue opVal = builder.emitBeginBorrowOperation(LI->getLoc(), val);+      if (opVal != val) {+        borrowedVals.push_back(opVal);+        val = opVal;+      }+    }     val = projection.createObjectProjection(builder, LI->getLoc(), val).get();   }+   op = LI->getOperand();-  LI->replaceAllUsesWith(val);+  // Replace users of the loaded value with `val`+  // If we have a load [copy], replace the users with copy_value of `val`+  if (LI->getOwnershipQualifier() == LoadOwnershipQualifier::Copy) {+    LI->replaceAllUsesWith(builder.createCopyValue(LI->getLoc(), val));+  } else {+    LI->replaceAllUsesWith(val);

Ah, you're right. I was thinking that isCaptured would reject that function but, it doesn't (which is obvious now that I have the example in front of me).

I started implementing it, but it started getting too complex and I don't want to add that in this PR.

This is where the ValueLifetimeAnalysis might come in handy.

meg-gupta

comment created time in 10 days

PullRequestReviewEvent

pull request commentapple/swift

[cxx-interop] Cast "data" to the correct type in _swift_dispatch_data_apply.

I think we've seen it sometimes non-deterministically, I suspect it is an incremental build issue.

I think you're right. That makes the most sense. I just saw all the other commits were all lldb stuff and this was a failure while building the stdlib. Thanks for looking into it :)

zoecarver

comment created time in 10 days

pull request commentapple/swift

[cxx-interop] Cast "data" to the correct type in _swift_dispatch_data_apply.

It's possible that this [1] build failure was caused by this patch. A (full) OS X test did succeed for this patch before it landed, though. Should I revert or wait until the next build also fails (or doesn't fail). I'll plan on the latter unless I hear otherwise.

[1] = https://ci.swift.org/job/oss-swift-incremental-RA-osx/12891/

zoecarver

comment created time in 11 days

Pull request review commentapple/swift

[ownership] Enable SILMem2Reg for OSSA

 static void collectLoads(SILInstruction *I, SmallVectorImpl<LoadInst *> &Loads) static void replaceLoad(LoadInst *LI, SILValue val, AllocStackInst *ASI) {   ProjectionPath projections(val->getType());   SILValue op = LI->getOperand();+  SILBuilderWithScope builder(LI);+   while (op != ASI) {     assert(isa<UncheckedAddrCastInst>(op) || isa<StructElementAddrInst>(op) ||            isa<TupleElementAddrInst>(op));     auto *Inst = cast<SingleValueInstruction>(op);     projections.push_back(Projection(Inst));     op = Inst->getOperand(0);   }-  SILBuilder builder(LI);++  SmallVector<SILValue, 4> borrowedVals;   for (auto iter = projections.rbegin(); iter != projections.rend(); ++iter) {     const Projection &projection = *iter;+    assert(projection.getKind() == ProjectionKind::BitwiseCast ||+           projection.getKind() == ProjectionKind::Struct ||+           projection.getKind() == ProjectionKind::Tuple);++    // struct_extract and tuple_extract expect guaranteed operand ownership+    // non-trivial RunningVal is owned. Insert borrow operation to convert+    if (projection.getKind() == ProjectionKind::Struct ||+        projection.getKind() == ProjectionKind::Tuple) {+      SILValue opVal = builder.emitBeginBorrowOperation(LI->getLoc(), val);+      if (opVal != val) {+        borrowedVals.push_back(opVal);+        val = opVal;+      }+    }     val = projection.createObjectProjection(builder, LI->getLoc(), val).get();   }+   op = LI->getOperand();-  LI->replaceAllUsesWith(val);+  // Replace users of the loaded value with `val`+  // If we have a load [copy], replace the users with copy_value of `val`+  if (LI->getOwnershipQualifier() == LoadOwnershipQualifier::Copy) {+    LI->replaceAllUsesWith(builder.createCopyValue(LI->getLoc(), val));+  } else {+    LI->replaceAllUsesWith(val);

But, we won't optimize something if there is a consuming use of a struct_element_addr. A use of a struct_element_addr has to be a load/store into the original stack alloc (which could never happen because they wouldn't be the correct type), or it would have to be an unsupported instruction. In other words, I think we would bail if there was a consuming use of a loaded struct_element_addr. Does that logic make sense?

meg-gupta

comment created time in 11 days

PullRequestReviewEvent

pull request commentapple/swift-corelibs-foundation

[cxx-interop] Fix two headers to be valid in C++ mode.

This seems legit to me, but as there's a way to test the toolchain PR with this without merging, I'll defer to the rest of the requested reviewers to merge it, unless it's urgent.

Not urgent. I'm just eager to get that other patch in 😁 I had forgotten that toolchain PR testing works, thanks for running that.

zoecarver

comment created time in 11 days

Pull request review commentapple/swift

[ownership] Enable SILMem2Reg for OSSA

 static void collectLoads(SILInstruction *I, SmallVectorImpl<LoadInst *> &Loads) static void replaceLoad(LoadInst *LI, SILValue val, AllocStackInst *ASI) {   ProjectionPath projections(val->getType());   SILValue op = LI->getOperand();+  SILBuilderWithScope builder(LI);+   while (op != ASI) {     assert(isa<UncheckedAddrCastInst>(op) || isa<StructElementAddrInst>(op) ||            isa<TupleElementAddrInst>(op));     auto *Inst = cast<SingleValueInstruction>(op);     projections.push_back(Projection(Inst));     op = Inst->getOperand(0);   }-  SILBuilder builder(LI);++  SmallVector<SILValue, 4> borrowedVals;   for (auto iter = projections.rbegin(); iter != projections.rend(); ++iter) {     const Projection &projection = *iter;+    assert(projection.getKind() == ProjectionKind::BitwiseCast ||+           projection.getKind() == ProjectionKind::Struct ||+           projection.getKind() == ProjectionKind::Tuple);++    // struct_extract and tuple_extract expect guaranteed operand ownership+    // non-trivial RunningVal is owned. Insert borrow operation to convert+    if (projection.getKind() == ProjectionKind::Struct ||+        projection.getKind() == ProjectionKind::Tuple) {+      SILValue opVal = builder.emitBeginBorrowOperation(LI->getLoc(), val);+      if (opVal != val) {+        borrowedVals.push_back(opVal);+        val = opVal;+      }+    }     val = projection.createObjectProjection(builder, LI->getLoc(), val).get();   }+   op = LI->getOperand();-  LI->replaceAllUsesWith(val);+  // Replace users of the loaded value with `val`+  // If we have a load [copy], replace the users with copy_value of `val`+  if (LI->getOwnershipQualifier() == LoadOwnershipQualifier::Copy) {+    LI->replaceAllUsesWith(builder.createCopyValue(LI->getLoc(), val));+  } else {+    LI->replaceAllUsesWith(val);

Is there any case where we would have a guaranteed value here? I don't think that's possible because the value we load must have been stored in the stack alloc at one point which means it must be an owned value.

meg-gupta

comment created time in 11 days

PullRequestReviewEvent

Pull request review commentapple/swift

[ownership] Enable SILMem2Reg for OSSA

 visitUncheckedTrivialBitCastInst(UncheckedTrivialBitCastInst *UTBCI) { SILInstruction * SILCombiner:: visitUncheckedBitwiseCastInst(UncheckedBitwiseCastInst *UBCI) {+  if (UBCI->getFunction()->hasOwnership())

I think this is an unrelated change. It looks like it's actually my fault.I missed it in d3a01131d758f41ec132b98cece6153c7a7e240f.

meg-gupta

comment created time in 11 days

PullRequestReviewEvent

PR merged apple/swift

Reviewers
[cxx-interop] Cast "data" to the correct type in _swift_dispatch_data_apply. C++ Interop

The implicit conversions are OK in C but C++ will error. To make this header valid in both C and C++ we should just always cast.

This and https://github.com/apple/swift-corelibs-foundation/pull/2895 fix the Linux builds for #32721.

+2 -2

5 comments

1 changed file

zoecarver

pr closed time in 11 days

push eventapple/swift

Zoe Carver

commit sha 722cc755f8ee5bd74eb8f6c4e7f0a6514838fd50

[cxx-interop] Cast data to the correct type. (#34266) The implicit conversions are OK in C but C++ will error. To make this header valid in both C and C++ we should just always cast.

view details

push time in 11 days

push eventmartinboehme/swift

zoecarver

commit sha 11f15b78c5db8cac6a9f8044f4a0e1648c9ef560

[cxx-interop] Remove logic around applying attributes. Removes the logic around applying attributes to C++ constructor's indirect results. Also fixes some commenting.

view details

push time in 11 days

Pull request review commentapple/swift

Add support for calling C++ constructors

+struct ExplicitDefaultConstructor {+  ExplicitDefaultConstructor() : x(42) {}+  int x;+};++struct ImplicitDefaultConstructor {

StructWithCopyConstructorAndValue accomplishes this.

martinboehme

comment created time in 11 days

PullRequestReviewEvent
more