profile
viewpoint
Varun Gandhi varungandhi-apple @Apple Work account for @typesanitizer

varungandhi-apple/swift 1

The Swift Programming Language

pull request commentapple/swift

[cxx-interop] Use regex instead of operand name to fix C++ constructor tests.

Down to a single failure now:

Swift(macosx-x86_64) :: Interop/Cxx/class/constructors-irgen.swift
zoecarver

comment created time in 19 hours

delete branch varungandhi-apple/swift

delete branch : vg-doc-update-external-resources

delete time in 2 days

push eventapple/swift

Varun Gandhi

commit sha 290923c344addc17cd9f4337ab27c2ac1c6402a1

[docs] Add links to 'The Swift runtime' posts + podcast episode. (#34446) Co-authored-by: Ben Rimmington <me@benrimmington.com>

view details

push time in 2 days

Pull request review commentapple/swift

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

 void ClangImporter::lookupRelatedEntity(   } } +NominalTypeDecl *+ClangImporter::instantiateCXXClassTemplate(+    clang::ClassTemplateDecl *decl,+    ArrayRef<clang::TemplateArgument> arguments) {+  void *InsertPos = nullptr;+  auto *ctsd = decl->findSpecialization(arguments, InsertPos);+  if (!ctsd) {+    ctsd = clang::ClassTemplateSpecializationDecl::Create(+        decl->getASTContext(), decl->getTemplatedDecl()->getTagKind(),+        decl->getDeclContext(), decl->getTemplatedDecl()->getBeginLoc(),+        decl->getLocation(), decl, arguments, nullptr);+    decl->AddSpecialization(ctsd, InsertPos);+  }++  auto CanonType = decl->getASTContext().getTypeDeclType(ctsd);+  assert(isa<clang::RecordType>(CanonType) &&+          "type of non-dependent specialization is not a RecordType");

(Sorry, missed this earlier.)

If Clang also does the same thing, I think it's fine. 👍🏼

hlopko

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentapple/swift

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

+// RUN: not %target-swift-emit-sil %s -I %S/Inputs -enable-cxx-interop 2>&1 | %FileCheck %s

(Sorry, missed this comment earlier.)

in my case I want assert that the error shows location in the header where the instantiation happened.

I see, I didn't realize that was happening. That makes sense.

hlopko

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentapple/swift

[cxx-interop] Fix infinite recursion of PackExpansion type.

 namespace {  #define SUGAR_TYPE(KIND)                                            \     ImportResult Visit##KIND##Type(const clang::KIND##Type *type) { \

We should probably have custom visitors for most if not all of them. But until then, we really shouldn't create an infinite loop by visiting the same type over and over again.

Ah OK, so this is intended as a stop-gap fix, not as a full solution. That's fine by me. 👍🏼 (Having an inline FIXME stating that the custom visitors need to be written would be nice though.)

+1 to Martin's idea of having test cases for the different potentially-sugared types.

zoecarver

comment created time in 2 days

PullRequestReviewEvent

pull request commentapple/swift

[docs] Add links to 'The Swift runtime' posts + podcast episode.

@swift-ci please smoke test

varungandhi-apple

comment created time in 2 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 4590c4adcb6d7167d62b2ff877d01d3190fa4fac

Update docs/ExternalResources.md Co-authored-by: Ben Rimmington <me@benrimmington.com>

view details

push time in 2 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 1ba3cef94456536e18dfdef5dfe398e31b5409a4

Update docs/ExternalResources.md Co-authored-by: Ben Rimmington <me@benrimmington.com>

view details

push time in 2 days

pull request commentapple/swift

[docs] Add links to 'The Swift runtime' posts + podcast episode.

@swift-ci please smoke test

varungandhi-apple

comment created time in 3 days

create barnchvarungandhi-apple/swift

branch : vg-doc-update-external-resources

created branch time in 3 days

delete branch varungandhi-apple/swift

delete branch : vg-revert-import-filtering-refactor

delete time in 3 days

push eventapple/swift

Varun Gandhi

commit sha 1f479896f4c12270cc8189f12f01622017db9df2

Revert "[NFC] Clarify semantics of getImportedModules." This reverts commit 4b5d8851147bed1f0945b7e23cbf788ce7869891.

view details

Varun Gandhi

commit sha d32a371df561def2cbdcdd23338a2a45a8e0597b

Merge pull request #34410 from varungandhi-apple/vg-revert-import-filtering-refactor Revert "[NFC] Clarify semantics of getImportedModules."

view details

push time in 3 days

PR merged apple/swift

Revert "[NFC] Clarify semantics of getImportedModules."

This reverts commit 4b5d8851147bed1f0945b7e23cbf788ce7869891.

Fixes rdar://70448782.

I will re-work and re-land the refactoring later.

+18 -68

3 comments

6 changed files

varungandhi-apple

pr closed time in 3 days

PullRequestReviewEvent

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()) {-        auto *boolExpr =-            new (context) BooleanLiteralExpr(value.getInt().getBoolValue(),-                                             SourceLoc(),-                                             /**Implicit=*/true);+      bool isBool = type->getCanonicalType()->isBool();+      // Check if "type" is a C++ enum with an underlying type of "bool".+      if (!isBool && type->getStructOrBoundGenericStruct() &&+          type->getStructOrBoundGenericStruct()->getClangDecl()) {+        if (auto enumDecl = dyn_cast<clang::EnumDecl>(+                type->getStructOrBoundGenericStruct()->getClangDecl())) {

You could simplify this a little bit by using dyn_cast_or_null.

zoecarver

comment created time in 3 days

PullRequestReviewEvent

pull request commentapple/swift

[cxx-interop] Disable importing fully specialized class templates.

@swift-ci test

zoecarver

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentapple/swift

[cxx-interop] Fix infinite recursion of PackExpansion type.

 namespace {  #define SUGAR_TYPE(KIND)                                            \     ImportResult Visit##KIND##Type(const clang::KIND##Type *type) { \

Is PackExpansion sometimes a sugared type and sometimes isn't? If so, shouldn't it have a hand-written Visit method instead of returning a bogus Type() when it is in canonical form?

zoecarver

comment created time in 3 days

PullRequestReviewEvent

pull request commentapple/swift

Fix snippet in OptimizationTips.rst

I looked at a toy example and both the retain and release seem to be happening in the caller.

valeriyvan

comment created time in 3 days

pull request commentapple/swift

Revert "[NFC] Clarify semantics of getImportedModules."

@swift-ci please test Linux

varungandhi-apple

comment created time in 6 days

pull request commentapple/swift

Revert "[NFC] Clarify semantics of getImportedModules."

@swift-ci please test

varungandhi-apple

comment created time in 6 days

PR opened apple/swift

Reviewers
Revert "[NFC] Clarify semantics of getImportedModules."

This reverts commit 4b5d8851147bed1f0945b7e23cbf788ce7869891.

Fixes rdar://70448782.

I will re-work and re-land the refactoring later.

+18 -68

0 comment

6 changed files

pr created time in 6 days

create barnchvarungandhi-apple/swift

branch : vg-revert-import-filtering-refactor

created branch time in 6 days

Pull request review commentapple/swift

Bring up tests + validation tests for the 'freestanding' build and the standalone_minimal preset

 else()   set(SWIFT_STDLIB_STABLE_ABI_default FALSE) endif() +if(SWIFT_BUILD_SDK_OVERLAY OR SWIFT_INCLUDE_TESTS)

This code seems to be assuming that we never invoke CMake in this directory directly, we always go through the top-level CMakeLists.txt in the swift/ directory. Is that assumption true (at least, it's not obvious to me that it's true)? Otherwise, these variables will be uninitialized.

We hit a similar issue in https://github.com/apple/swift/pull/34371#issue-507213229:

In direct CMake calls to stdlib/public/Platform/CMakeLists.txt, the variable SWIFT_STDLIB_STABLE_ABI is not initialized.

kubamracek

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentapple/swift

Bring up tests + validation tests for the 'freestanding' build and the standalone_minimal preset

 else()   set(SWIFT_STDLIB_STABLE_ABI_default FALSE) endif() +if(SWIFT_BUILD_SDK_OVERLAY OR SWIFT_INCLUDE_TESTS)+  set(SWIFT_BUILD_TEST_SUPPORT_MODULES_default TRUE)+else()+  set(SWIFT_BUILD_TEST_SUPPORT_MODULES_default FALSE)+endif()

Could you simplify this to something like:

set(SWIFT_BUILD_TEST_SUPPORT_MODULES_default
    (SWIFT_BUILD_SDK_OVERLAY OR SWIFT_INCLUDE_TESTS))
kubamracek

comment created time in 6 days

PullRequestReviewEvent

pull request commentapple/swift

[cxx-interop] Support bool-based enums.

If that's the case, please add a comment indicating why the APInt condition doesn't imply the Bool condition. Otherwise, someone reading the code later might have the same question that I had.

zoecarver

comment created time in 7 days

PullRequestReviewEvent

Pull request review commentapple/swift

[Docs] Clarifies `ObjectIdentifier` guarantees

 /// /// In Swift, only class instances and metatypes have unique identities. There /// is no notion of identity for structs, enums, functions, or tuples.+///+/// `ObjectIdentifier` is only guaranteed to remain unique for the+/// lifetime of an object. 

[Sorry if this seems like nit-picking but:] This doesn't sound quite right. ObjectIdentifier is a type. It is not the type which is unique, values of that type are unique at runtime. This is why I suggested:

The unique identity for a class instance is only valid for comparisons during
the lifetime of the instance. 

The "unique identity" corresponds to values of type ObjectIdentifier, and IMO fits better stylistically with the rest of the doc comment, which also uses "unique identities" as shorthand for "values of type ObjectIdentifier".

sunbohong

comment created time in 7 days

PullRequestReviewEvent

pull request commentapple/swift

[nfc] Make getMangledName a virtual member of ClangModuleLoader.

I think that's a good idea when the changes stand on their own. For example, splitting out a cleanup/refactoring is generally a good idea, since it is possible to judge a refactoring PR on its own without more context, and the feature PR itself becomes smaller and easier to review. In this particular case, you are introducing a method with no callers for that method, so it doesn't really stand on its own IMO.

zoecarver

comment created time in 8 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?

zoecarver

comment created time in 8 days

Pull request review commentapple/swift

[Docs] Clarifies `ObjectIdentifier` guarantees

 /// /// In Swift, only class instances and metatypes have unique identities. There /// is no notion of identity for structs, enums, functions, or tuples.+///+/// `ObjectIdentifier` is only guaranteed to remain unique for the+/// lifetime of an object. When the instance gets deallocated, its object +/// identifier may be reused for a different object. (Internally, objects are+/// identified by their memory location.)

I'm not really sure whether we really want to have wording for allocation/deallocation/memory locations here. That makes it seem like we are making some commitments about the memory allocation under the hood, but I'm not sure if we want to do that. How about something simpler:

The unique identity for a class instance is only valid for comparisons during
the lifetime of the instance. The unique identity for a metatype is always valid.

You could also omit the second sentence I suggested above if you think it's not helpful.

sunbohong

comment created time in 8 days

PullRequestReviewEvent

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci smoke test and merge

varungandhi-apple

comment created time in 8 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 987d055b8c69347a4cd8533d7b59c7ceaccee0fe

[Mangler] Handle mangling for Clang types not derivable from Swift types.

view details

Varun Gandhi

commit sha 6cb71c6b457d17b16046d56777fe378b22c8d8bb

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 8 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);

In practice, sometimes the Mod pointer is null (I haven't checked when exactly), so the tests crash if I do that.

varungandhi-apple

comment created time in 8 days

PullRequestReviewEvent

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) {

Is the first check for isBool() necessary or is the second check for getBitWidth() == 1 sufficient?

zoecarver

comment created time in 8 days

PullRequestReviewEvent

push eventapple/swift

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

Varun Gandhi

commit sha ada53b112f1dc0999a572292121744432c3c2f8f

Merge pull request #34371 from varungandhi-apple/vg-cmake-Darwin-library-evolution [CMake] Make sure that library evolution is set when compiling overlays.

view details

push time in 8 days

delete branch varungandhi-apple/swift

delete branch : vg-cmake-Darwin-library-evolution

delete time in 8 days

PR merged apple/swift

Reviewers
[CMake] Make sure that library evolution is set when compiling overlays.

If library evolution is not set, the generated swiftinterface will be incorrect, leading to further errors downstream.

In direct CMake calls to stdlib/public/Platform/CMakeLists.txt, the variable SWIFT_STDLIB_STABLE_ABI is not initialized. For now, we duplicate the logic in stdlib/CMakeLists.txt to make sure that it is initialized properly. We can potentially de-duplicate it later.

Fixes rdar://70156840.

+17 -6

3 comments

2 changed files

varungandhi-apple

pr closed time in 8 days

pull request commentapple/swift

[CMake] Make sure that library evolution is set when compiling overlays.

@swift-ci please smoke test

varungandhi-apple

comment created time in 9 days

Pull request review commentapple/swift

[CMake] Make sure that library evolution is set when compiling overlays.

 set(SWIFT_NATIVE_CLANG_TOOLS_PATH "${TOOLCHAIN_DIR}/usr/bin" CACHE STRING set(SWIFT_NATIVE_SWIFT_TOOLS_PATH "${TOOLCHAIN_DIR}/usr/bin" CACHE STRING   "Path to Swift tools that are executable on the build machine.") +# HACK: This initialization code is duplicated in stdlib/CMakeLists.txt++if("${SWIFT_HOST_VARIANT_SDK}" MATCHES "(OSX|IOS*|TVOS*|WATCHOS*)")+  # All Darwin platforms have ABI stability.+  set(SWIFT_STDLIB_STABLE_ABI_default TRUE)+elseif("${SWIFT_HOST_VARIANT_SDK}" STREQUAL "LINUX")

Removed.

varungandhi-apple

comment created time in 9 days

PullRequestReviewEvent

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha dd4a9f3bde5c960e9b35bb662698cfe8d5c0a730

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

view details

push time in 9 days

pull request commentapple/swift

[CMake] Make sure that library evolution is set when compiling overlays.

@swift-ci please smoke test

varungandhi-apple

comment created time in 9 days

pull request commentapple/swift

[CMake] Make sure that library evolution is set when compiling overlays.

cc @porglezomp

varungandhi-apple

comment created time in 9 days

PR opened apple/swift

Reviewers
[CMake] Make sure that library evolution is set when compiling overlays.

If library evolution is not set, the generated swiftinterface will be incorrect, leading to further errors downstream.

In direct CMake calls to stdlib/public/Platform/CMakeLists.txt, the variable SWIFT_STDLIB_STABLE_ABI is not initialized. For now, we duplicate the logic in stdlib/CMakeLists.txt to make sure that it is initialized properly.

Fixes rdar://70156840.

+43 -6

0 comment

2 changed files

pr created time in 9 days

create barnchvarungandhi-apple/swift

branch : vg-cmake-Darwin-library-evolution

created branch time in 9 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows

varungandhi-apple

comment created time in 14 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test

varungandhi-apple

comment created time in 14 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha e90e486b237d29e34cf3624b9ea7ed09ea0b3c78

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 14 days

Pull request review commentapple/swift

Update function type mangling to use Clang type when applicable.

 class TypePrinter : public TypeVisitor<TypePrinter> {     visit(staticSelfT);   } -  void printFunctionExtInfo(ASTContext &Ctx, AnyFunctionType::ExtInfo info) {+  void printFunctionExtInfo(AnyFunctionType *fnType) {+    auto &Ctx = fnType->getASTContext();

Fixed.

varungandhi-apple

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentapple/swift

Update function type mangling to use Clang type when applicable.

 void Remangler::mangleImplFunctionType(Node *node) {         break;       }       case Node::Kind::ImplFunctionAttribute: {-        char FuncAttr = llvm::StringSwitch<char>(Child->getText())-                        .Case("@convention(block)", 'B')-                        .Case("@convention(c)", 'C')-                        .Case("@convention(method)", 'M')-                        .Case("@convention(objc_method)", 'O')-                        .Case("@convention(closure)", 'K')-                        .Case("@convention(witness_method)", 'W')-                        .Case("@yield_once", 'A')-                        .Case("@yield_many", 'G')-                        .Case("@async", 'H')-                        .Default(0);+        StringRef text = Child->hasText()

Refactored out.

varungandhi-apple

comment created time in 14 days

PullRequestReviewEvent

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);

I'm passing in a function type primarily because we need access to the ASTContext in the method's implementation, and ASTMangler doesn't carry an ASTContext. Is there a way to get the ASTContext directly from the ASTMangler?

varungandhi-apple

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentapple/swift

Update function type mangling to use Clang type when applicable.

 class OldDemangler {     return true;   } -  void addImplFunctionAttribute(NodePointer parent, StringRef attr,-                         Node::Kind kind = Node::Kind::ImplFunctionAttribute) {-    parent->addChild(Factory.createNode(kind, attr), Factory);+  void addImplFunctionAttribute(+      NodePointer parent, StringRef attr, bool forConvention = false,+      Node::Kind kind = Node::Kind::ImplFunctionAttribute) {+    if (!forConvention) {+      parent->addChild(Factory.createNode(kind, attr), Factory);+      return;+    }+    auto attrNode = Factory.createNode(Node::Kind::ImplFunctionAttribute);+    attrNode->addChild(+        Factory.createNode(Node::Kind::ImplFunctionConventionName, attr),+        Factory);+    parent->addChild(attrNode, Factory);

Added a new ImplFunctionConvention node which carries one or two children depending on the exact convention.

varungandhi-apple

comment created time in 14 days

PullRequestReviewEvent

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 74d20e727be7d62eeaedc7ec14a2e8ad639f8e90

[Mangler] Handle mangling for Clang types not derivable from Swift types.

view details

Varun Gandhi

commit sha ccd6d2f07d2ee778f5acdf80f2a5dceb6dbd98f4

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 14 days

pull request commentapple/swift

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

I think the failure:

<unknown>:0: error: fatal error encountered during compilation; please file a bug report with your project and the crash log
<unknown>:0: note: Cannot read '/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/buildbot_incremental/swift-macosx-x86_64/./lib/swift/iphoneos/layouts-arm64.yaml'

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

zoecarver

comment created time in 15 days

pull request commentapple/swift

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

@swift-ci test

zoecarver

comment created time in 16 days

PullRequestReviewEvent

Pull request review commentapple/swift

Update function type mangling to use Clang type when applicable.

  import ctypes -// CHECK: f1: (@convention(c, cType: "int (*)(int)") (Swift.Int32) -> Swift.Int32)?+// CHECK: f1: (@convention(c, cType: "size_t (*)(size_t)") (Swift.Int) -> Swift.Int)?

It's for ergonomics. Swift uses Int for sizes: Array.count returns an Int, not a UInt. Casting for addition/subtraction would make code more verbose.

varungandhi-apple

comment created time in 16 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test

varungandhi-apple

comment created time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows

varungandhi-apple

comment created time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows

varungandhi-apple

comment created time in 20 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 44b017c8e827d28b312b2089736a57f1f9420de7

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows

varungandhi-apple

comment created time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows

varungandhi-apple

comment created time in 20 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 3259548c05ec07786153d7dedb96e87deb0f6bb0

[Mangler] Handle mangling for Clang types not derivable from Swift types.

view details

Varun Gandhi

commit sha 1c435702385d8313a5aabc5911b91bb9b476f1c7

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

Now the issue is size_t expands to unsigned long long on Windows, not unsigned long, which still means that the mangling is different on Windows. Fixing that...

varungandhi-apple

comment created time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows platform

varungandhi-apple

comment created time in 20 days

pull request commentapple/swift

Update function type mangling to use Clang type when applicable.

@swift-ci please test Windows platform

varungandhi-apple

comment created time in 21 days

push eventvarungandhi-apple/swift

Varun Gandhi

commit sha 7917bc66d12583295ecd3dff84ec84bbb46f1b81

[Mangler] Handle mangling for Clang types not derivable from Swift types.

view details

Varun Gandhi

commit sha 2aa73a1dc964a068577d36de6ca38cb8848d3d42

[ASTPrinter] Print Clang type only if not derivable from Swift type.

view details

push time in 21 days

pull request commentapple/swift

Add check for Xcode version compatibility

Also, is there a specific reason it is an environment variable instead of a flag? I wrote the comment earlier related to documenting it, but I just realized, if it were a flag, there would be a natural place for documenting it.

keith

comment created time in 21 days

pull request commentapple/swift

Add check for Xcode version compatibility

What would be the right place to document the SKIP_XCODE_VERSION_CHECK environment variable?

keith

comment created time in 21 days

Pull request review commentapple/swift

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

+// RUN: %empty-directory(%t)+// RUN: %target-build-swift %S/Inputs/SwiftClassInstantiationModule.swift -module-name SwiftClassInstantiationModule -emit-module -emit-module-path %t/ -I %S/Inputs -Xfrontend -enable-cxx-interop -parse-as-library+// RUN: %target-swift-ide-test -print-module -module-to-print=SwiftClassInstantiationModule -I %t -I %S/Inputs -source-filename=x -enable-cxx-interop | %FileCheck %s++// CHECK: import MagicWrapper+// CHECK: import SwiftOnoneSupport

Is there a specific reason we are checking for import SwiftOnoneSupport here? We generally emit it for (almost?) every module, so I don't think we need to check for it explicitly here.

hlopko

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentapple/swift

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

+// RUN: %empty-directory(%t)+// RUN: %target-build-swift %S/Inputs/SwiftClassInstantiationModule.swift -module-name SwiftClassInstantiationModule -emit-module -emit-module-path %t/ -I %S/Inputs -Xfrontend -enable-cxx-interop -parse-as-library+// RUN: %target-swift-ide-test -print-module -module-to-print=SwiftClassInstantiationModule -I %t -I %S/Inputs -source-filename=x -enable-cxx-interop | %FileCheck %s

To clarify whether I'm understanding this test correctly: is the main idea here that you emit a swiftinterface and are checking that swiftinterface? If that's the case, then:

  1. Why are mangled names showing up in the swiftinterface?

  2. You could simplify the RUN commands to something like: (taken from test/ModuleInterface/attrs.swift)

    // RUN: %target-swift-frontend -typecheck -emit-module-interface-path %t.swiftinterface -enable-library-evolution %s
    // RUN: %FileCheck %s < %t.swiftinterface
    
hlopko

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentapple/swift

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

 void ClangImporter::lookupRelatedEntity(   } } +NominalTypeDecl *+ClangImporter::instantiateCXXClassTemplate(+    clang::ClassTemplateDecl *decl,+    ArrayRef<clang::TemplateArgument> arguments) {+  void *InsertPos = nullptr;+  auto *ctsd = decl->findSpecialization(arguments, InsertPos);+  if (!ctsd) {+    ctsd = clang::ClassTemplateSpecializationDecl::Create(+        decl->getASTContext(), decl->getTemplatedDecl()->getTagKind(),+        decl->getDeclContext(), decl->getTemplatedDecl()->getBeginLoc(),+        decl->getLocation(), decl, arguments, nullptr);+    decl->AddSpecialization(ctsd, InsertPos);+  }++  auto CanonType = decl->getASTContext().getTypeDeclType(ctsd);+  assert(isa<clang::RecordType>(CanonType) &&+          "type of non-dependent specialization is not a RecordType");

Could this happen because of an internal error (this check is already handled elsewhere but maybe there's a bug there) or is this potentially because of a user error? If it could be because of a user error, please at least add a TODO for surfacing a diagnostic here.

hlopko

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentapple/swift

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

+// RUN: not %target-swift-emit-sil %s -I %S/Inputs -enable-cxx-interop 2>&1 | %FileCheck %s

Could you use %target-swift-emit-sil -verify (I think that should work...) instead of using %FileCheck here? We generally check diagnostics using -verify, not with FileCheck. If the errors are being emitting during SILGen, you could use %target-swift-emit-silgen.

hlopko

comment created time in 21 days

PullRequestReviewEvent
more