profile
viewpoint
Suyash Srijan theblixguy @theappbusiness London, United Kingdom http://www.suyashsrijan.com 24. iOS Engineer currently working at @theappbusiness. Swift compiler collaborator.

apple/swift 53945

The Swift Programming Language

theblixguy/ForceDoze 101

Enable Doze mode immediately after screen off and turn off motion sensing to get best battery life

theblixguy/DroidID 81

DroidID - Unlock your Mac using your Android phone's fingerprint sensor!

theblixguy/LittleSwift 27

A simple self-hosted Swift compiler

theblixguy/AppOps 23

Independent AppOps app for Android

theblixguy/AppOpsKitKat 5

Access AppOps on latest Android Kitkat revision

theblixguy/CustomDroid 5

CustomDroid allows you to tweak your newly purchased phone.

theblixguy/CrashWindows 3

Crashes Windows by doing stupid stuff at kernel level

theblixguy/AutoScrollr 2

Automatically scroll content in any app!

theblixguy/ADBRecoveryScreenshot 1

Takes screenshot of device's screen when in recovery mode

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

SIL: Verify invariants of async_continuation instructions.

Thanks for applying the FullApplySite suggestion - the change looks good to me!

jckarter

comment created time in 17 days

Pull request review commentapple/swift

SIL: Verify invariants of async_continuation instructions.

 MultipleValueInstruction *MultipleValueInstructionResult::getParent() {   return reinterpret_cast<MultipleValueInstruction *>(value); } +/// Returns true if evaluation of this node may cause suspension of an+/// async task.+bool SILNode::maySuspend() const {+  // await_async_continuation always suspends the current task.+  if (isa<AwaitAsyncContinuationInst>(this))+    return true;+  +  // Fully applying an async function may suspend the caller.+  if (auto i = dyn_cast<SILInstruction>(this)) {+    if (isa<FullApplySite>(i)) {

Just a minor suggestion, but I think you can do

    if (auto FAI = FullApplySite::isa(&i)) {

and use FAI.getOrigCalleeType() which should simplify some code below.

jckarter

comment created time in 18 days

PullRequestReviewEvent
PullRequestReviewEvent

delete branch theblixguy/swift

delete branch : fix/SR-4723

delete time in 21 days

PR closed apple/swift

[CSDiagnostics] When emitting rawValue init fix-it, check if there's a label-less init

If we have the following code:

enum Foo: RawRepresentable {
  init(_ rawValue: Int) {}
  init(rawValue: Int) {}
  var rawValue: Int { return 0 }
}

func takesFoo(_: Foo) {}
takesFoo(0)

We'll trigger the following error:

cannot convert value of type 'Int' to expected argument type 'Foo'

along with a fix-it to insert Foo(rawValue:):

takesFoo(0)
         ^
         Foo(rawValue:  )

After fix-it is applied -> takesFoo(Foo(rawValue: 0))

However, Foo also has a label-less init (_: rawValue: Int), which would be nicer to use instead:

takesFoo(0)
         ^
         Foo( )

After fix-it is applied -> takesFoo(Foo(0))

Resolves SR-4723 Resolves rdar://problem/32265506

+61 -1

14 comments

2 changed files

theblixguy

pr closed time in 21 days

PullRequestReviewEvent

delete branch theblixguy/swift

delete branch : feature/diagnose-oob-array-subscript

delete time in 24 days

PR closed apple/swift

Reviewers
[SILOptimizer] Diagnose out-of-bounds literal array subscript

This PR adds a new method to constant folding to diagnose out-of-bounds subscript access on array literals.

(see discussion here: https://forums.swift.org/t/checking-out-of-bounds-access-on-compile-time-in-sil/27064/25)

+206 -9

10 comments

5 changed files

theblixguy

pr closed time in 24 days

Pull request review commentapple/swift

SR-12022: refactor LiteralExpr to combine common initializer code

 static bool hasUnownedInnerPointerResult(CanSILFunctionType fnType) {   return false; } +//===----------------------------------------------------------------------===//+//                  Argument Emission for Builtin Initializer+//===----------------------------------------------------------------------===//+static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        StringLiteralExpr *stringLiteral) {+  return emitStringLiteral(SGF, stringLiteral, stringLiteral->getValue(), C,+                           stringLiteral->getEncoding());+}++static inline PreparedArguments+buildBuiltinLiteralArgs(NilLiteralExpr *nilLiteral) {+  PreparedArguments builtinLiteralArgs;+  builtinLiteralArgs.emplace({});+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        BooleanLiteralExpr *booleanLiteral) {+  PreparedArguments builtinLiteralArgs;+  auto i1Ty = SILType::getBuiltinIntegerType(1, SGF.getASTContext());+  SILValue boolValue = SGF.B.createIntegerLiteral(booleanLiteral, i1Ty,+                                                  booleanLiteral->getValue());+  ManagedValue boolManaged = ManagedValue::forUnmanaged(boolValue);+  CanType ty = boolManaged.getType().getASTType()->getCanonicalType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(booleanLiteral, RValue(SGF, {boolManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        IntegerLiteralExpr *integerLiteral) {+  PreparedArguments builtinLiteralArgs;+  ManagedValue integerManaged =+      ManagedValue::forUnmanaged(SGF.B.createIntegerLiteral(+          integerLiteral,+          SILType::getBuiltinIntegerLiteralType(SGF.getASTContext()),+          integerLiteral->getRawValue()));+  CanType ty = integerManaged.getType().getASTType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(integerLiteral, RValue(SGF, {integerManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        FloatLiteralExpr *floatLiteral) {+  PreparedArguments builtinLiteralArgs;+  auto *litTy = floatLiteral->getBuiltinType()->castTo<BuiltinFloatType>();+  ManagedValue floatManaged =+      ManagedValue::forUnmanaged(SGF.B.createFloatLiteral(+          floatLiteral,+          SILType::getBuiltinFloatType(litTy->getFPKind(), SGF.getASTContext()),+          floatLiteral->getValue()));++  CanType ty = floatManaged.getType().getASTType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(floatLiteral, RValue(SGF, {floatManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        MagicIdentifierLiteralExpr *magicLiteral) {+  ASTContext &ctx = SGF.getASTContext();+  SourceLoc loc = magicLiteral->getStartLoc();++  switch (magicLiteral->getKind()) {+  case MagicIdentifierLiteralExpr::FileIDSpelledAsFile:+  case MagicIdentifierLiteralExpr::FileID: {+    std::string value = loc.isValid() ? SGF.getMagicFileIDString(loc) : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::FilePathSpelledAsFile:+  case MagicIdentifierLiteralExpr::FilePath: {+    StringRef value = loc.isValid() ? SGF.getMagicFilePathString(loc) : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::Function: {+    StringRef value = loc.isValid() ? SGF.getMagicFunctionString() : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::Line:+  case MagicIdentifierLiteralExpr::Column: {+    SourceLoc Loc = magicLiteral->getStartLoc();+    unsigned Value = 0;+    if (Loc.isValid()) {+      Value = magicLiteral->getKind() == MagicIdentifierLiteralExpr::Line+                  ? ctx.SourceMgr.getPresumedLineAndColumnForLoc(Loc).first+                  : ctx.SourceMgr.getPresumedLineAndColumnForLoc(Loc).second;+    }++    auto silTy = SILType::getBuiltinIntegerLiteralType(ctx);+    auto ty = silTy.getASTType();+    SILValue integer = SGF.B.createIntegerLiteral(magicLiteral, silTy, Value);+    ManagedValue integerManaged = ManagedValue::forUnmanaged(integer);+    PreparedArguments builtinLiteralArgs;+    builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+    builtinLiteralArgs.add(magicLiteral, RValue(SGF, {integerManaged}, ty));+    return builtinLiteralArgs;+  }+  case MagicIdentifierLiteralExpr::DSOHandle:+    llvm_unreachable("handled elsewhere");+  }+}++static inline PreparedArguments buildBuiltinLiteralArgs(SILGenFunction &SGF,+                                                        SGFContext C,+                                                        LiteralExpr *literal) {+  if (auto stringLiteral = dyn_cast<StringLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, stringLiteral);+  } else if (auto nilLiteral = dyn_cast<NilLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(nilLiteral);+  } else if (auto booleanLiteral = dyn_cast<BooleanLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, booleanLiteral);+  } else if (auto integerLiteral = dyn_cast<IntegerLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, integerLiteral);+  } else if (auto floatLiteral = dyn_cast<FloatLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, floatLiteral);+  } else {+    return buildBuiltinLiteralArgs(+        SGF, C, cast<MagicIdentifierLiteralExpr>(literal));+  }+  llvm_unreachable("bad literal expr");

It’s not needed since the cast above will trigger an assert if one passes a different literal expression.

Interfere

comment created time in 24 days

PullRequestReviewEvent

Pull request review commentapple/swift

SR-12022: refactor LiteralExpr to combine common initializer code

 static bool hasUnownedInnerPointerResult(CanSILFunctionType fnType) {   return false; } +//===----------------------------------------------------------------------===//+//                  Argument Emission for Builtin Initializer+//===----------------------------------------------------------------------===//+static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        StringLiteralExpr *stringLiteral) {+  return emitStringLiteral(SGF, stringLiteral, stringLiteral->getValue(), C,+                           stringLiteral->getEncoding());+}++static inline PreparedArguments+buildBuiltinLiteralArgs(NilLiteralExpr *nilLiteral) {+  PreparedArguments builtinLiteralArgs;+  builtinLiteralArgs.emplace({});+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        BooleanLiteralExpr *booleanLiteral) {+  PreparedArguments builtinLiteralArgs;+  auto i1Ty = SILType::getBuiltinIntegerType(1, SGF.getASTContext());+  SILValue boolValue = SGF.B.createIntegerLiteral(booleanLiteral, i1Ty,+                                                  booleanLiteral->getValue());+  ManagedValue boolManaged = ManagedValue::forUnmanaged(boolValue);+  CanType ty = boolManaged.getType().getASTType()->getCanonicalType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(booleanLiteral, RValue(SGF, {boolManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        IntegerLiteralExpr *integerLiteral) {+  PreparedArguments builtinLiteralArgs;+  ManagedValue integerManaged =+      ManagedValue::forUnmanaged(SGF.B.createIntegerLiteral(+          integerLiteral,+          SILType::getBuiltinIntegerLiteralType(SGF.getASTContext()),+          integerLiteral->getRawValue()));+  CanType ty = integerManaged.getType().getASTType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(integerLiteral, RValue(SGF, {integerManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        FloatLiteralExpr *floatLiteral) {+  PreparedArguments builtinLiteralArgs;+  auto *litTy = floatLiteral->getBuiltinType()->castTo<BuiltinFloatType>();+  ManagedValue floatManaged =+      ManagedValue::forUnmanaged(SGF.B.createFloatLiteral(+          floatLiteral,+          SILType::getBuiltinFloatType(litTy->getFPKind(), SGF.getASTContext()),+          floatLiteral->getValue()));++  CanType ty = floatManaged.getType().getASTType();+  builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+  builtinLiteralArgs.add(floatLiteral, RValue(SGF, {floatManaged}, ty));+  return builtinLiteralArgs;+}++static inline PreparedArguments+buildBuiltinLiteralArgs(SILGenFunction &SGF, SGFContext C,+                        MagicIdentifierLiteralExpr *magicLiteral) {+  ASTContext &ctx = SGF.getASTContext();+  SourceLoc loc = magicLiteral->getStartLoc();++  switch (magicLiteral->getKind()) {+  case MagicIdentifierLiteralExpr::FileIDSpelledAsFile:+  case MagicIdentifierLiteralExpr::FileID: {+    std::string value = loc.isValid() ? SGF.getMagicFileIDString(loc) : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::FilePathSpelledAsFile:+  case MagicIdentifierLiteralExpr::FilePath: {+    StringRef value = loc.isValid() ? SGF.getMagicFilePathString(loc) : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::Function: {+    StringRef value = loc.isValid() ? SGF.getMagicFunctionString() : "";+    return emitStringLiteral(SGF, magicLiteral, value, C,+                             magicLiteral->getStringEncoding());+  }++  case MagicIdentifierLiteralExpr::Line:+  case MagicIdentifierLiteralExpr::Column: {+    SourceLoc Loc = magicLiteral->getStartLoc();+    unsigned Value = 0;+    if (Loc.isValid()) {+      Value = magicLiteral->getKind() == MagicIdentifierLiteralExpr::Line+                  ? ctx.SourceMgr.getPresumedLineAndColumnForLoc(Loc).first+                  : ctx.SourceMgr.getPresumedLineAndColumnForLoc(Loc).second;+    }++    auto silTy = SILType::getBuiltinIntegerLiteralType(ctx);+    auto ty = silTy.getASTType();+    SILValue integer = SGF.B.createIntegerLiteral(magicLiteral, silTy, Value);+    ManagedValue integerManaged = ManagedValue::forUnmanaged(integer);+    PreparedArguments builtinLiteralArgs;+    builtinLiteralArgs.emplace(AnyFunctionType::Param(ty));+    builtinLiteralArgs.add(magicLiteral, RValue(SGF, {integerManaged}, ty));+    return builtinLiteralArgs;+  }+  case MagicIdentifierLiteralExpr::DSOHandle:+    llvm_unreachable("handled elsewhere");+  }+}++static inline PreparedArguments buildBuiltinLiteralArgs(SILGenFunction &SGF,+                                                        SGFContext C,+                                                        LiteralExpr *literal) {+  if (auto stringLiteral = dyn_cast<StringLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, stringLiteral);+  } else if (auto nilLiteral = dyn_cast<NilLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(nilLiteral);+  } else if (auto booleanLiteral = dyn_cast<BooleanLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, booleanLiteral);+  } else if (auto integerLiteral = dyn_cast<IntegerLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, integerLiteral);+  } else if (auto floatLiteral = dyn_cast<FloatLiteralExpr>(literal)) {+    return buildBuiltinLiteralArgs(SGF, C, floatLiteral);+  } else {+    return buildBuiltinLiteralArgs(+        SGF, C, dyn_cast<MagicIdentifierLiteralExpr>(literal));

I think you should either use cast or move it into an if check like above and add a llvm_unreachable at the end. This is so we crash here if someone adds a new literal expression but doesn’t update this function.

Interfere

comment created time in 24 days

PullRequestReviewEvent

Pull request review commentapple/swift

[Property Wrappers] Support local property wrappers

 VarDecl *VarDecl::getPropertyWrapperProjectionVar() const {   return getPropertyWrapperBackingPropertyInfo().projectionVar; } +void VarDecl::visitAuxiliaryDecls(llvm::function_ref<void(VarDecl *)> visit) const {+  if (getDeclContext()->isTypeContext())+    return;++  if (auto *backingVar = getPropertyWrapperBackingProperty())+    visit(backingVar);++  if (auto *projectionVar = getPropertyWrapperProjectionVar())+    visit(projectionVar);+}

Awesome! There’s an old WIP PR for it: https://github.com/apple/swift/pull/27600 which you may find helpful.

hborla

comment created time in 24 days

PullRequestReviewEvent

Pull request review commentapple/swift

[Property Wrappers] Support local property wrappers

 VarDecl *VarDecl::getPropertyWrapperProjectionVar() const {   return getPropertyWrapperBackingPropertyInfo().projectionVar; } +void VarDecl::visitAuxiliaryDecls(llvm::function_ref<void(VarDecl *)> visit) const {+  if (getDeclContext()->isTypeContext())+    return;++  if (auto *backingVar = getPropertyWrapperBackingProperty())+    visit(backingVar);++  if (auto *projectionVar = getPropertyWrapperProjectionVar())+    visit(projectionVar);+}

Should this visit the lazy backing storage as well?

hborla

comment created time in 24 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentSwiftWeekly/swiftweekly.github.io

[170] Issue #170 - October 8, 2020

https://forums.swift.org/t/unlock-existential-types-for-all-protocols/40665

fassko

comment created time in 25 days

Pull request review commentapple/swift

[Concurrency] Introduce Actor protocol to which actor classes all conform

+//===--- DerivedConformanceEquatableHashable.cpp - Derived Equatable & co -===//

Nit:

//===--- DerivedConformanceActor.cpp - Derived Actor conformance -----------===//
DougGregor

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

Update CHANGELOG.md for #34005

You can file a new JIRA ticket and link it in the changelog.

AnthonyLatsis

comment created time in a month

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 void ConformanceChecker::resolveValueWitnesses() {       break;     }   }++  // Emit a tailored diagnostic when we have witnesses to+  // '@objc' requirements which are default implementations.+  if (!objcRequirementsWithDefaultImpl.empty()) {+    SourceLoc FixItLocation;+    SourceLoc TypeLoc;+    auto DC = Conformance->getDeclContext();+    if (auto Extension = dyn_cast<ExtensionDecl>(DC)) {+      FixItLocation = Extension->getBraces().Start;+      TypeLoc = Extension->getStartLoc();+    } else if (auto Nominal = dyn_cast<NominalTypeDecl>(DC)) {+      FixItLocation = Nominal->getBraces().Start;+      TypeLoc = Nominal->getStartLoc();+    } else {+      llvm_unreachable("Unknown adopter kind");+    }++    auto &Diags = getASTContext().Diags;+    Diags.diagnose(TypeLoc, diag::type_does_not_conform, Conformance->getType(),+                   Proto->getDeclaredInterfaceType());+    Diags.diagnose(TypeLoc, diag::witness_objc_default_implementation);++    if (getASTContext().LangOpts.DiagnosticsEditorMode) {+      llvm::SmallString<128> FixItString;+      llvm::raw_svector_ostream FixItStream(FixItString);+      for (auto requirement : objcRequirementsWithDefaultImpl) {+        printRequirementStub(requirement, Conformance->getDeclContext(),

Here’s an idea (may or may not be good) - what if we didn’t consider the default implementation as a legitimate witness in this case? Then we’ll end up in the “missing witnesses” path which can deal with stubs and etc. We can just emit the tailored note here.

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 void ConformanceChecker::resolveValueWitnesses() {       break;     }   }++  // Emit a tailored diagnostic when we have witnesses to+  // '@objc' requirements which are default implementations.+  if (!objcRequirementsWithDefaultImpl.empty()) {+    SourceLoc FixItLocation;+    SourceLoc TypeLoc;+    auto DC = Conformance->getDeclContext();+    if (auto Extension = dyn_cast<ExtensionDecl>(DC)) {+      FixItLocation = Extension->getBraces().Start;+      TypeLoc = Extension->getStartLoc();+    } else if (auto Nominal = dyn_cast<NominalTypeDecl>(DC)) {+      FixItLocation = Nominal->getBraces().Start;+      TypeLoc = Nominal->getStartLoc();+    } else {+      llvm_unreachable("Unknown adopter kind");+    }++    auto &Diags = getASTContext().Diags;+    Diags.diagnose(TypeLoc, diag::type_does_not_conform, Conformance->getType(),+                   Proto->getDeclaredInterfaceType());+    Diags.diagnose(TypeLoc, diag::witness_objc_default_implementation);++    if (getASTContext().LangOpts.DiagnosticsEditorMode) {+      llvm::SmallString<128> FixItString;+      llvm::raw_svector_ostream FixItStream(FixItString);+      for (auto requirement : objcRequirementsWithDefaultImpl) {+        printRequirementStub(requirement, Conformance->getDeclContext(),

Yes! One of them with have a note attached to it to say that default implementations are not allowed. I guess that's not ideal...

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 void ConformanceChecker::resolveValueWitnesses() {       break;     }   }++  // Emit a tailored diagnostic when we have witnesses to+  // '@objc' requirements which are default implementations.+  if (!objcRequirementsWithDefaultImpl.empty()) {+    SourceLoc FixItLocation;+    SourceLoc TypeLoc;+    auto DC = Conformance->getDeclContext();+    if (auto Extension = dyn_cast<ExtensionDecl>(DC)) {+      FixItLocation = Extension->getBraces().Start;+      TypeLoc = Extension->getStartLoc();+    } else if (auto Nominal = dyn_cast<NominalTypeDecl>(DC)) {+      FixItLocation = Nominal->getBraces().Start;+      TypeLoc = Nominal->getStartLoc();+    } else {+      llvm_unreachable("Unknown adopter kind");+    }++    auto &Diags = getASTContext().Diags;+    Diags.diagnose(TypeLoc, diag::type_does_not_conform, Conformance->getType(),+                   Proto->getDeclaredInterfaceType());+    Diags.diagnose(TypeLoc, diag::witness_objc_default_implementation);++    if (getASTContext().LangOpts.DiagnosticsEditorMode) {+      llvm::SmallString<128> FixItString;+      llvm::raw_svector_ostream FixItStream(FixItString);+      for (auto requirement : objcRequirementsWithDefaultImpl) {+        printRequirementStub(requirement, Conformance->getDeclContext(),

Missing witnesses will be handled by existing code, so we don't need to check for that here. The difference here is that the witness isn't missing (the default implementation is the witness), so I am not sure if it makes sense to unify the code with the "missing witnesses" code elsewhere, but if this isn't the right place to do this check then I would appreciate some suggestions on where to move it to!

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Concurrency] Import "did" delegate methods as @asyncHandler.

 ERROR(asynchandler_async,none, ERROR(asynchandler_inout_parameter,none,       "'inout' parameter is not allowed in '@asyncHandler' function",       ())+ERROR(asynchandler_unsafe_pointer_parameter,none,+      "'%0' parameter is not allowed in `@asyncHandler` function",
      "'%0' parameter is not allowed in '@asyncHandler' function",
DougGregor

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 NOTE(objc_optional_requirement_swift_rename,none,      "rename %select{method|initializer|property|subscript}0 to match "      "requirement %1", (bool, DeclName)) +ERROR(witness_objc_default_implementation, none, +      "default implementations cannot be used to satisfy requirements of "+      "'@objc' protocols, such as %0 in '@objc' protocol %1", (DeclName, DeclName))

Great idea, I have done that now. Let me know what you think!

theblixguy

comment created time in a month

PullRequestReviewEvent

push eventtheblixguy/swift

Brian Gontowski

commit sha 3425a6dbb16e5fa7ad4b735eff4533c279d61442

Added protocol to support CVarArg objects that need to be retained

view details

Brian Gontowski

commit sha 0e7749bcde5eb1bc9fec82ef0eb3896ec8d6de6f

Fixed comment

view details

Yuta Saito

commit sha d6cddaabb59958737e048ff1a5dd4d283c555661

[LTO] Support LLVM LTO for driver This commit adds LTO support for handling linker options and LLVM BC emission. Even for ELF, swift-autolink-extract is unnecessary because linker options are embeded in LLVM BC content when LTO.

view details

Brian Gontowski

commit sha 17c77ba703b32c11e127573d414d31c9ec635188

Only use _CVarArgObject on non-ObjC platforms

view details

Brian Gontowski

commit sha 515c371be434ff49debfd145ebd9047bd148d47f

Avoid a warning when not modifying arg

view details

Michael Gottesman

commit sha c8d4d168f7981fc0b6cadedd71c2e340c622bcb3

Revert "build-script: remove dead CMake options for Swift" This reverts commit 95102bc258a6b30ba2349d561ef56ea48c601cae. This is actually a dead option that is relied upon for some configurations. I am going to add a note to not touch the option. I talked with compnerd about this and they are cool with this. I think that we can redo this in a nicer way when we are further into the build-script-impl refactoring. I added a note to the code to explain that it isn't dead.

view details

Hamish Knight

commit sha a7a8d9fd260bd2d5d1a213100c4000f5618e39bf

[AST] Remove NewBodyKind default A bunch of callers were accidentally misusing it.

view details

Hamish Knight

commit sha 9b8b2068d2931a60cd495fab59e3204c16db2d0f

Add AbstractFunctionDecl::getTypecheckedBody Refactor TypeCheckFunctionBodyRequest to return the type-checked body, and remove `typeCheckAbstractFunctionBody` in favor of a method on AbstractFunctionDecl. In addition, start returning an ErrorExpr body instead of a partially type-checked body if type-checking fails.

view details

Hamish Knight

commit sha 8fd6d7e19a9d8acf58cdd1182015df76ac88ea97

Add some missing calls to setThrows We no longer run error checking for already type-checked synthesized functions, so add a couple of `setThrows` calls where they were previously missing.

view details

Hamish Knight

commit sha 28246a7596dcc565b827b3666b9e4bed9adf6911

[SILGen] Use getTypecheckedBody Use `getTypecheckedBody` to allow lazy type-checking when emitting function definitions.

view details

Saleem Abdulrasool

commit sha 7128611a9d90b69a93a2adf8b01360ead0eedace

AST: align `ImportedModule` to 64-bits Align `ImportedModule` to 64-bits as it is used in other types which force the 8-byte alignment for the layout.

view details

Varun Gandhi

commit sha e48469d03c87f8c1b87a2462fa3cd8c27c4d685f

[NFC] Add missing invariant checks for ExtInfoBuilders.

view details

Denys Shabalin

commit sha 87906df2fec1b138b281f405f3de42fd8ab685ee

Add missing SWIFT_FALLTHROUGH to the tryCastToString

view details

Varun Gandhi

commit sha 384edd1f2b9c64d96dec169460b232f4ce14223f

[docs] Link 'The Swift Runtime' blog posts in ExternalResources.md.

view details

freddi

commit sha 495087f26f4a0288a8cf66be1829304ac403c43b

[sil-opt] Fix to satisfy all trapping instruction case at SILInstruction::mayTrap

view details

Denys Shabalin

commit sha 78c957f485b7f2e0cc42057fab65d354855b89bc

Move fallthrough one line up

view details

Robert Widmann

commit sha 98765132c90af02b445e77988ba1d7047bbc57b5

[Gardening] Document a Strange Sort

view details

Pavel Yaskevich

commit sha 7b0e46bdfadded96df9c8d5673734c9475e8d5bd

[ConstraintSystem] Adjust impact of a missing member fix Currently its impact is set to be less than that of a conversion fix, which is incorrect. Let's adjust that and increase it even farther for cases where base is `Any` or `AnyObject`. We couldn't do it for `Any` before because it was used to represent type holes, but it's no longer the case. Resolves: rdar://problem/68155466

view details

Varun Gandhi

commit sha 58fcc4602da3412ecf958b2f62c6465ae0ef27d7

[docs] Fix typos and broken links.

view details

Varun Gandhi

commit sha 296d25294b53618ebe25603ba3a508067a5ad1db

[docs] Add link to FAQ in README.

view details

push time in a month

Pull request review commentapple/swift

[Concurrency] Handle partial application of actor-isolated methods.

 class IsolationRestriction {  } +namespace {+  /// Describes the important parts of a partial apply thunk.+  struct PartialApplyThunkInfo {+    Expr *base;+    Expr *fn;+    bool isEscaping;+  };+}++/// Try to decompose a call that might be an invocation of a partial apply+/// thunk.+static Optional<PartialApplyThunkInfo> decomposePartialApplyThunk(+    ApplyExpr *apply, Expr *parent) {+  // Check for a call to the outer closure in the thunk.+  auto outerAutoclosure = dyn_cast<AutoClosureExpr>(apply->getFn());+  if (!outerAutoclosure ||

I think you can use getUnwrappedCurryThunkExpr() on outerAutoclosure to dig out the DeclRefExpr of the function.

DougGregor

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 NOTE(objc_optional_requirement_swift_rename,none,      "rename %select{method|initializer|property|subscript}0 to match "      "requirement %1", (bool, DeclName)) +ERROR(witness_objc_default_implementation, none, +      "default implementations cannot be used to satisfy requirements of "+      "'@objc' protocols, such as %0 in '@objc' protocol %1", (DeclName, DeclName))

Hmm that's similar to what I suggested earlier, but @amomchilov pointed out that it doesn't make it clear enough that the idea of using default implementations is not allowed in general for @objc protocols and instead it makes it look like that there is something wrong with the particular requirement, so I tweaked the wording a bit.

I have another idea - we can take what you suggested above and also include this bit: default implementations cannot be used to satisfy requirements of '@objc' protocols. It makes the diagnostic text a bit longer, though.

theblixguy

comment created time in a month

PullRequestReviewEvent

push eventtheblixguy/swift

Brian Gontowski

commit sha 3425a6dbb16e5fa7ad4b735eff4533c279d61442

Added protocol to support CVarArg objects that need to be retained

view details

Brian Gontowski

commit sha 0e7749bcde5eb1bc9fec82ef0eb3896ec8d6de6f

Fixed comment

view details

Yuta Saito

commit sha d6cddaabb59958737e048ff1a5dd4d283c555661

[LTO] Support LLVM LTO for driver This commit adds LTO support for handling linker options and LLVM BC emission. Even for ELF, swift-autolink-extract is unnecessary because linker options are embeded in LLVM BC content when LTO.

view details

Brian Gontowski

commit sha 17c77ba703b32c11e127573d414d31c9ec635188

Only use _CVarArgObject on non-ObjC platforms

view details

Brian Gontowski

commit sha 515c371be434ff49debfd145ebd9047bd148d47f

Avoid a warning when not modifying arg

view details

Michael Gottesman

commit sha c8d4d168f7981fc0b6cadedd71c2e340c622bcb3

Revert "build-script: remove dead CMake options for Swift" This reverts commit 95102bc258a6b30ba2349d561ef56ea48c601cae. This is actually a dead option that is relied upon for some configurations. I am going to add a note to not touch the option. I talked with compnerd about this and they are cool with this. I think that we can redo this in a nicer way when we are further into the build-script-impl refactoring. I added a note to the code to explain that it isn't dead.

view details

Hamish Knight

commit sha a7a8d9fd260bd2d5d1a213100c4000f5618e39bf

[AST] Remove NewBodyKind default A bunch of callers were accidentally misusing it.

view details

Hamish Knight

commit sha 9b8b2068d2931a60cd495fab59e3204c16db2d0f

Add AbstractFunctionDecl::getTypecheckedBody Refactor TypeCheckFunctionBodyRequest to return the type-checked body, and remove `typeCheckAbstractFunctionBody` in favor of a method on AbstractFunctionDecl. In addition, start returning an ErrorExpr body instead of a partially type-checked body if type-checking fails.

view details

Hamish Knight

commit sha 8fd6d7e19a9d8acf58cdd1182015df76ac88ea97

Add some missing calls to setThrows We no longer run error checking for already type-checked synthesized functions, so add a couple of `setThrows` calls where they were previously missing.

view details

Hamish Knight

commit sha 28246a7596dcc565b827b3666b9e4bed9adf6911

[SILGen] Use getTypecheckedBody Use `getTypecheckedBody` to allow lazy type-checking when emitting function definitions.

view details

Saleem Abdulrasool

commit sha 7128611a9d90b69a93a2adf8b01360ead0eedace

AST: align `ImportedModule` to 64-bits Align `ImportedModule` to 64-bits as it is used in other types which force the 8-byte alignment for the layout.

view details

Varun Gandhi

commit sha e48469d03c87f8c1b87a2462fa3cd8c27c4d685f

[NFC] Add missing invariant checks for ExtInfoBuilders.

view details

Denys Shabalin

commit sha 87906df2fec1b138b281f405f3de42fd8ab685ee

Add missing SWIFT_FALLTHROUGH to the tryCastToString

view details

Varun Gandhi

commit sha 384edd1f2b9c64d96dec169460b232f4ce14223f

[docs] Link 'The Swift Runtime' blog posts in ExternalResources.md.

view details

freddi

commit sha 495087f26f4a0288a8cf66be1829304ac403c43b

[sil-opt] Fix to satisfy all trapping instruction case at SILInstruction::mayTrap

view details

Denys Shabalin

commit sha 78c957f485b7f2e0cc42057fab65d354855b89bc

Move fallthrough one line up

view details

Robert Widmann

commit sha 98765132c90af02b445e77988ba1d7047bbc57b5

[Gardening] Document a Strange Sort

view details

Pavel Yaskevich

commit sha 7b0e46bdfadded96df9c8d5673734c9475e8d5bd

[ConstraintSystem] Adjust impact of a missing member fix Currently its impact is set to be less than that of a conversion fix, which is incorrect. Let's adjust that and increase it even farther for cases where base is `Any` or `AnyObject`. We couldn't do it for `Any` before because it was used to represent type holes, but it's no longer the case. Resolves: rdar://problem/68155466

view details

Varun Gandhi

commit sha 58fcc4602da3412ecf958b2f62c6465ae0ef27d7

[docs] Fix typos and broken links.

view details

Varun Gandhi

commit sha 296d25294b53618ebe25603ba3a508067a5ad1db

[docs] Add link to FAQ in README.

view details

push time in a month

pull request commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

Ping. Any thoughts on the new diagnostic wording?

theblixguy

comment created time in a month

push eventapple/swift

Suyash Srijan

commit sha 6ef4b0db4b23e996856d31f8b7934ecb9fabda0e

[SILGen] Emit unreachable code diagnostic for single expression closures with implicit returns too (#33604) * [SILGen] Emit unreachable code diagnostics for single expression closures with implicit returns too * [Test] Update diagnostic in test/SILGen/functions_uninhabited_param.swift

view details

push time in a month

delete branch theblixguy/swift

delete branch : fix/SR-13432

delete time in a month

PR merged apple/swift

Reviewers
[SILGen] Emit unreachable code diagnostic for single expression closures with implicit returns too

We don't emit unreachable code diagnostic for single expression closures if it has an implicit return. For example:

func map<T>(_ block: (Never) -> T) {}
map { _ in return 5 } // warning: will never be executed
map { _ in 5 } // no warning

This is because we skip implicit statements in SILGen if we encounter an unreachable location.

For implicit return statements in single expression closure or functions, the result expression is not implicit. So, let's use this knowledge to prevent skipping over the return statement.


Resolves SR-13432

+29 -1

7 comments

2 changed files

theblixguy

pr closed time in a month

pull request commentapple/swift

[SILGen] Emit unreachable code diagnostic for single expression closures with implicit returns too

@swift-ci please smoke test

theblixguy

comment created time in a month

pull request commentapple/swift

[Changelog] Add release date for Swift 5.3

🏆

theblixguy

comment created time in a month

push eventapple/swift

Suyash Srijan

commit sha c4761832465eb2da0fd1a4769885efeccb1bf315

[Changelog] Add release date for Swift 5.3 (#33973) Add the release date for Swift 5.3 and the Xcode version in which it shipped.

view details

push time in a month

delete branch apple/swift

delete branch : update-changelog-swift-5.3-release-date

delete time in a month

PR merged apple/swift

[Changelog] Add release date for Swift 5.3

Add the release date for Swift 5.3 and the Xcode version in which it shipped.

+1 -1

2 comments

1 changed file

theblixguy

pr closed time in a month

Pull request review commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

 typealias Y = ErrorA<ErrorB>  typealias Id<T> = T -extension Id {} // expected-error {{non-nominal type 'Id' cannot be extended}}+extension Id {} // expected-error {{generic type 'Id' cannot be extended}}

Okay, I think extension Id is equivalent to extension Any (which is disallowed) and extension Id<Type> (which is disallowed) is equivalent to extension Id where T == Type (which is also disallowed). I cannot suggest to the user do the former or latter and it seems to me that there is just no way to extend Id at all. It is, however, possible to extend Type directly, so perhaps I can say generic type 'Id' cannot be extended; extension must be declared on a concrete type or something similar (need to think more about wording).

theblixguy

comment created time in a month

PullRequestReviewEvent

push eventtheblixguy/swift

Suyash Srijan

commit sha 8aeda94c60fe29770482d30420a1d41ffc216422

[Diagnostics] Adjust wording for associated_type_witness_conform_impossible diagnostic

view details

push time in a month

push eventtheblixguy/swift

Suyash Srijan

commit sha b3ee1073f87ad27be6afde3d04f164258143d866

[NFC] Change spelling from 'typealias' to 'type alias' for TypeAlias TypeKind description

view details

Suyash Srijan

commit sha 956bf62eddcb3e72eeb47d76e095cb4c1ec4d1a5

[Diagnostics] Adjust wording for associated_type_witness_conform_impossible diagnostic

view details

push time in a month

pull request commentapple/swift

[Changelog] Add release date for Swift 5.3

@swift-ci please smoke test

theblixguy

comment created time in a month

PR opened apple/swift

[Changelog] Add release date for Swift 5.3

Add the release date for Swift 5.3 and the Xcode version in which it shipped.

+1 -1

0 comment

1 changed file

pr created time in a month

create barnchapple/swift

branch : update-changelog-swift-5.3-release-date

created branch time in a month

Pull request review commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

 typealias Y = ErrorA<ErrorB>  typealias Id<T> = T -extension Id {} // expected-error {{non-nominal type 'Id' cannot be extended}}+extension Id {} // expected-error {{generic type 'Id' cannot be extended}}

Ah, I misunderstood. I think the core problem here is that we have an unbound generic type, so I think the error should say that we cannot extend this type without specifying what the generic parameter is.

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

 typealias Y = ErrorA<ErrorB>  typealias Id<T> = T -extension Id {} // expected-error {{non-nominal type 'Id' cannot be extended}}+extension Id {} // expected-error {{generic type 'Id' cannot be extended}}

Oops, thats my mistake. I should’ve used “generic parameter” instead of “generic type”. Does that sound better though?

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

 protocol P12 { extension Int : P11 {} struct S3 : P12 { // expected-error {{type 'S3' does not conform to protocol 'P12'}}     func bar() -> P11 { return 0 }-    // expected-note@-1 {{candidate can not infer 'A' = 'P11' because 'P11' is not a nominal type and so can't conform to 'P11'}}+    // expected-note@-1 {{candidate can not infer 'A' = 'P11' because 'P11' is not a struct, class or enum type and so can't conform to 'P11'}}

Good point, I think what you propose sounds a lot better! I’ll tweak the text.

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

 getCanonicalParams(AnyFunctionType *funcType,   } } +StringRef TypeBase::getKindName(TypeKind K) {+#define ENTRY(Kind, String)                                                    \+  case TypeKind::Kind:                                                         \+    return String+  switch (K) {+    ENTRY(Error, "error type");+    ENTRY(Unresolved, "unresolved type");+    ENTRY(Hole, "hole type");+    ENTRY(TypeVariable, "type variable type");++    ENTRY(BuiltinInteger, "builtin type");+    ENTRY(BuiltinIntegerLiteral, "builtin type");+    ENTRY(BuiltinFloat, "builtin type");+    ENTRY(BuiltinRawPointer, "builtin type");+    ENTRY(BuiltinNativeObject, "builtin type");+    ENTRY(BuiltinUnsafeValueBuffer, "builtin type");+    ENTRY(BuiltinVector, "builtin type");+    ENTRY(BuiltinBridgeObject, "builtin type");++    ENTRY(Tuple, "tuple type");++    ENTRY(WeakStorage, "weak storage type");+    ENTRY(UnownedStorage, "unowned storage type");+    ENTRY(UnmanagedStorage, "unmanaged storage type");++    ENTRY(Enum, "enum type");+    ENTRY(Struct, "struct type");+    ENTRY(Class, "class type");+    ENTRY(Protocol, "protocol type");++    ENTRY(BoundGenericClass, "class type");+    ENTRY(BoundGenericEnum, "enum type");+    ENTRY(BoundGenericStruct, "struct type");++    ENTRY(UnboundGeneric, "generic type");++    ENTRY(Metatype, "metatype");+    ENTRY(ExistentialMetatype, "protocol metatype");++    // Calling this 'module' instead of 'module type'+    // because we don't want users to think of+    // module as types.+    ENTRY(Module, "module");++    ENTRY(DynamicSelf, "dynamic self type");++    ENTRY(PrimaryArchetype, "generic parameter type");+    ENTRY(OpaqueTypeArchetype, "opaque type");+    ENTRY(OpenedArchetype, "protocol type");+    ENTRY(NestedArchetype, "associated type");++    ENTRY(GenericTypeParam, "generic parameter type");+    ENTRY(DependentMember, "dependent member type");++    ENTRY(Function, "function type");+    ENTRY(GenericFunction, "function type");++    ENTRY(SILFunction, "SIL function type");+    ENTRY(SILBlockStorage, "SIL block storage type");+    ENTRY(SILBox, "SIL box type");+    ENTRY(SILToken, "SIL token type");++    ENTRY(ProtocolComposition, "protocol composition type");++    ENTRY(LValue, "lvalue type");+    ENTRY(InOut, "inout type");+    ENTRY(Paren, "paren type");++    // 'typealias' sounds better than 'typealias type'.+    ENTRY(TypeAlias, "typealias");

You’re right, the declaration is spelled as “type alias” there (I use the keyword spelling). I can see two diagnostics currently where the spellings diverge, but I think it would be better to stick with TSPL in my opinion.

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 struct EnumToVoidBuilder {   static func buildBlock(_ :MyEnum, _: MyEnum, _: MyEnum) {} } func acceptBuilder(@EnumToVoidBuilder body: () -> Void) {}++@_functionBuilder+struct AnyBuilder {+  static func buildBlock(_ components: Any...) -> Any { 5 }++  static func #^IN_FUNCTION_BUILDER_DECL^#+}++// IN_FUNCTION_BUILDER_DECL: Begin completions, 8 items+// IN_FUNCTION_BUILDER_DECL: Pattern/CurrNominal:                buildBlock(_ components: Any...) -> Any { {|}; name=buildBlock(_ components: Any...) -> Any {; comment=Required by every

Hmm, sure, that seems reasonable. What do you think about using placeholders for types if a declaration already exists? Right now, I think inserting one would trigger a redeclaration error and using placeholders for types can help avoid that.

DougGregor

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 bool TypeChecker::typeSupportsBuilderOp(   return foundMatch; } +Type swift::inferFunctionBuilderComponentType(NominalTypeDecl *builder) {+  Type componentType;++  SmallVector<ValueDecl *, 4> potentialMatches;+  ASTContext &ctx = builder->getASTContext();+  bool supportsBuildBlock = TypeChecker::typeSupportsBuilderOp(+      builder->getDeclaredInterfaceType(), builder, ctx.Id_buildBlock,+      /*argLabels=*/{}, &potentialMatches);+  if (supportsBuildBlock) {+    for (auto decl : potentialMatches) {+      auto func = dyn_cast<FuncDecl>(decl);+      if (!func || !func->isStatic())+        continue;++      // If we haven't seen a component type before, gather it.+      if (!componentType) {+        componentType = func->getResultInterfaceType();+        continue;+      }++      // If there are inconsistent component types, bail out.+      if (!componentType->isEqual(func->getResultInterfaceType())) {+        componentType = Type();+        break;+      }+    }+  }++  return componentType;+}++void swift::printFunctionBuilderBuildFunction(

It would be great to use this for the "missing buildBlock" case too in visitFunctionBuilderAttr!

DougGregor

comment created time in a month

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 struct EnumToVoidBuilder {   static func buildBlock(_ :MyEnum, _: MyEnum, _: MyEnum) {} } func acceptBuilder(@EnumToVoidBuilder body: () -> Void) {}++@_functionBuilder+struct AnyBuilder {+  static func buildBlock(_ components: Any...) -> Any { 5 }++  static func #^IN_FUNCTION_BUILDER_DECL^#

It might be good to add another test where we don't have static func to test the path where we insert it if it's missing.

DougGregor

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 struct EnumToVoidBuilder {   static func buildBlock(_ :MyEnum, _: MyEnum, _: MyEnum) {} } func acceptBuilder(@EnumToVoidBuilder body: () -> Void) {}++@_functionBuilder+struct AnyBuilder {+  static func buildBlock(_ components: Any...) -> Any { 5 }++  static func #^IN_FUNCTION_BUILDER_DECL^#+}++// IN_FUNCTION_BUILDER_DECL: Begin completions, 8 items+// IN_FUNCTION_BUILDER_DECL: Pattern/CurrNominal:                buildBlock(_ components: Any...) -> Any { {|}; name=buildBlock(_ components: Any...) -> Any {; comment=Required by every

Hmm, I think inserting this would conflict with existing buildBlock declaration. Perhaps we should only suggest adding build* methods that aren't explicitly declared by the user in the function builder type?

DougGregor

comment created time in a month

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 NOTE(function_builder_buildblock_enum_case, none, NOTE(function_builder_buildblock_not_static_method, none,      "potential match 'buildBlock' is not a static method", ()) +NOTE(function_builder_missing_build_optional, none,+     "add 'buildOptional(_:)' to the function builder %0 to add support for "+     "'if' statements without an 'else'", (Type))+NOTE(function_builder_missing_build_either, none,+     "add 'buildEither(first:)' and `buildEither(second:)' to the function "
     "add 'buildEither(first:)' and 'buildEither(second:)' to the function "
DougGregor

comment created time in a month

Pull request review commentapple/swift

[Function builders] Fix-Its and code completion improvements

 class CompletionOverrideLookup : public swift::VisibleDeclConsumer {     }   } +  static StringRef getFunctionBuilderDocComment(+      FunctionBuilderBuildFunction function) {+    switch (function) {+    case FunctionBuilderBuildFunction::BuildArray:+      return "Enables support for..in loops in a function builder by "+        "combining the results of all iterations into a single result";++    case FunctionBuilderBuildFunction::BuildBlock:+      return "Required by every function builder to build combined results "+          "from statement blocks";++    case FunctionBuilderBuildFunction::BuildEitherFirst:+      return "With buildEither(second:), enables support for 'if-else' and "+          "'switch' statements by folding conditional results into a single "+          "result";++    case FunctionBuilderBuildFunction::BuildEitherSecond:+      return "With buildEither(first:), enables support for 'if-else' and "+          "'switch' statements by folding conditional results into a single "+          "result";++    case FunctionBuilderBuildFunction::BuildExpression:+      return "If declared, provides contextual type information for statement "+          "expressions to translate them into partial results";++    case FunctionBuilderBuildFunction::BuildFinalResult:+      return "If declared, this will be called on the partial result from the "+          "outermost block statement to produce the final returned result";++    case FunctionBuilderBuildFunction::BuildLimitedAvailability:+      return "If declaration, this will be called on the partial result of "
      return "If declared, this will be called on the partial result of "
DougGregor

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

Just wondering if anyone has any more feedback or is this good to go?

theblixguy

comment created time in a month

pull request commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

@swift-ci please smoke test

theblixguy

comment created time in a month

PullRequestReviewEvent

pull request commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

@swift-ci please smoke test

theblixguy

comment created time in a month

push eventtheblixguy/swift

Suyash Srijan

commit sha d18147051578a70e612189fdfbaf71c2c1214bde

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements and omit the 'add @objc' fix-it

view details

push time in a month

pull request commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

@swift-ci please smoke test

theblixguy

comment created time in a month

push eventtheblixguy/swift

Suyash Srijan

commit sha dc0a8250f8aa97c046ee84b50c2f38570bfb701d

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements and omit the 'add @objc' fix-it

view details

push time in a month

Pull request review commentapple/swift

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements

 NOTE(objc_optional_requirement_swift_rename,none,      "requirement %1", (bool, DeclName))  ERROR(witness_non_objc,none,-      "non-'@objc' " OBJC_DIAG_SELECT " does not satisfy requirement "-      "of '@objc' protocol %2",-      (unsigned, DeclName, Identifier))+      "non-'@objc' " OBJC_DIAG_SELECT_1 " %select{cannot be used as a default implementation to satisfy|does not satisfy}0 requirement "+      "of '@objc' protocol %3",+      (bool, unsigned, DeclName, Identifier))

Done ✅

theblixguy

comment created time in a month

PullRequestReviewEvent

push eventtheblixguy/swift

Suyash Srijan

commit sha 05177e9769ec03f0d542d008c12653fc4c17ce65

[Sema] Add a tailored diagnostic for default implementations of '@objc' protocol requirements and omit the 'add @objc' fix-it

view details

push time in a month

pull request commentapple/swift

[NFC] Remove uses of 'nominal' from diagnostic text

@swift-ci please smoke test

theblixguy

comment created time in a month

push eventtheblixguy/swift

Suyash Srijan

commit sha 979d784ab1bf3a9583845b0cad6e48a5889a0aca

[Test] Fix a failing SourceKit test

view details

push time in a month

Pull request review commentapple/swift

[Sema] Tweak non-objc witness diagnostic when it comes from protocol extension

 NOTE(objc_optional_requirement_swift_rename,none,      "requirement %1", (bool, DeclName))  ERROR(witness_non_objc,none,-      "non-'@objc' " OBJC_DIAG_SELECT " does not satisfy requirement "-      "of '@objc' protocol %2",-      (unsigned, DeclName, Identifier))+      "non-'@objc' " OBJC_DIAG_SELECT_1 " %select{cannot be used as a default implementation to satisfy|does not satisfy}0 requirement "+      "of '@objc' protocol %3",+      (bool, unsigned, DeclName, Identifier))

I agree. I was also thinking of something similar but yours seems a little more compact than mine... I’ll update it. Thanks!

theblixguy

comment created time in a month

PullRequestReviewEvent

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials for All Protocols++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting implementation**+++### Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error `[the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements`. This proposal aims to relax this artificial constraint imposed on such protocols.+++### Motivation++Currently, any protocol that has `Self` or associated type requirements is not allowed to be used as a type. Initially, this restriction reflected technical limitations (as Joe states [here](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025)); however, such limitations have now been alleviated. As a result, users are left unable to utilize a powerful feature for certain protocols. That’s evident in a plethora of projects. For instance, the Standard Library has existential types such as [`AnyHashable`](https://developer.apple.com/documentation/swift/anyhashable) and [`AnyCollection`](https://developer.apple.com/documentation/swift/anycollection) and SwiftUI has [`AnyView`](https://developer.apple.com/documentation/swiftui/anyview). ++Generics are most often the best mechanism for type-level abstraction, which relies on the compiler knowing type information during compilation. However, type information is not always a gurantee, which is why the value-level abstraction of existential types is extremely useful in some cases.++One such case is heterogenous collections, which require value-level abstraction to store their elements of various types:++```swift+protocol Identifiable {+    associatedtype ID: Hashable +    +    var id: ID { get }+}++struct AnyIdentifiable { +    typealias ID = AnyHashable+    +    var id: ID { ... }+}++let myIdentifiables: [AnyIdentifiable]+```++Furthermore, dynamic environments are also known to lack type information. Therefore value-level abstraction can be exploited in cases such as previewing an application, where the application's components are dynamically replaced, in the file system where a file representing an unknown type might be stored, and in server environments, where various types could be exchanged between different computers.++All in all, supporting existential types for all protocols is useful for many situations that involve dynamicity. Moreover, there are many questions by language users asking about this behavior. Taking everything into consideration, we are confident that addressing this abnormality in the language will build a stronger foundation for [future additions](https://forums.swift.org/t/improving-the-ui-of-generics/22814) .+++### Proposed Solution++We propose that the constraint prohibiting the use of some protocols as types be lifted. As a result, boilerplate code in many projects - especially libraries and frameworks - will be significantly reduced.+++### Detailed Design ++Should this proposal be accepted, the compiler would no longer differentiate between protocols that don’t have `Self` or associated type requirements and those that do. However, some restrictions would apply to the use of requirements referencing associated types as seen in the below examples.++#### Examples:++1. Regular Protocol++```swift+protocol Foo {+    var bar: Int { get }+}++let foo: Foo = ... ✅++let bar: Int = foo.bar ✅+++extension Foo {+    var baz: Self { +        self+    }++    var opaqueSelf: some Foo {+        self+    }+}++let baz: some Foo =+    foo.baz ✅+    +let opaqueSelf: some Foo =+    foo.opaqueSelf ✅+```++ 2. Protocol with `Self` and Associated Type Requirements ++```swift+protocol Foo {+    associatedtype Bar+    +    var bar: Bar { get }+}++let foo: Foo = ... ✅ +++let bar: Any = foo.bar ❌+// We don’t know what type +// `Bar` is on the existential+// type of `Foo`.

It would be nice to have this feature to complement the “fixed associatedtype” feature. I am not very familiar with associatedtype implementation, but I don’t think it will be difficult to support this.

On the other hand, I think what we have now is “good enough” for a first step and also helps keep the proposal simple. There’s definitely more to do but remaining features can be added via future proposals.

filip-sakel

comment created time in a month

PullRequestReviewEvent

pull request commentapple/swift

[sil-opt] Fix covering all-case of trapping instruction of SILInstruction::mayTrap

macOS failure should be fixed once https://github.com/apple/swift-package-manager/pull/2924 is merged.

freddi-kit

comment created time in a month

pull request commentapple/swift

[sil-opt] Fix covering all-case of trapping instruction of SILInstruction::mayTrap

@swift-ci please test macOS

freddi-kit

comment created time in a month

pull request commentapple/swift

[sil-opt] Fix covering all-case of trapping instruction of SILInstruction::mayTrap

@swift-ci please test Windows

freddi-kit

comment created time in a month

pull request commentapple/swift

[sil-opt] Fix covering all-case of trapping instruction of SILInstruction::mayTrap

@swift-ci please test macOS

freddi-kit

comment created time in a month

pull request commentapple/swift

[sil-opt] Fix covering all-case of trapping instruction of SILInstruction::mayTrap

@swift-ci please test

freddi-kit

comment created time in a month

Pull request review commentapple/swift-evolution

Unlock Existential Types for All Protocols

+# Unlock Existentials for All Protocols++* Proposal: [SE-NNNN](NNNN-unlock-existential-types-for-all-protocols.md)+* Authors: [Anthony Latsis](https://github.com/AnthonyLatsis), [Filip Sakel](https://github.com/filip-sakel), [Suyash Srijan](https://github.com/theblixguy)+* Review Manager: TBD+* Status: **Awaiting Review**+* Implementation: [apple/swift#33767](https://github.com/apple/swift/pull/33767)+++### Introduction++Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error `[the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements`. This proposal aims to relax this artificial constraint imposed on such protocols.+++### Motivation++Currently, any protocol that has [non-covariant](https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)) `Self` references or associated type requirements is not allowed to be used as a type. Initially, this restriction reflected technical limitations (as Joe states [here](https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025)); however, such limitations have now been alleviated. As a result, users are left unable to utilize a powerful feature for certain protocols. That’s evident in a plethora of projects. For instance, the Standard Library has existential types such as [`AnyHashable`](https://developer.apple.com/documentation/swift/anyhashable) and [`AnyCollection`](https://developer.apple.com/documentation/swift/anycollection) and SwiftUI has [`AnyView`](https://developer.apple.com/documentation/swiftui/anyview). ++Generics are most often the best mechanism for type-level abstraction, which relies on the compiler knowing type information during compilation. However, type information is not always a gurantee, which is why the value-level abstraction of existential types is extremely useful in some cases.++One such case is heterogenous collections, which require value-level abstraction to store their elements of various types:++```swift+protocol Identifiable {+  associatedtype ID: Hashable +    +  var id: ID { get }+}++let naiveIdentifiables: [Identifiable] ❌+// The compiler doesn't currently allow that.+// So, we work around that by creating a+// custom existential type: 'AnyIdentifiable'.+++struct AnyIdentifiable { +  typealias ID = AnyHashable+    +  var id: ID { ... }+}++let myIdentifiables: [AnyIdentifiable] ✅+```++Furthermore, dynamic environments are also known to lack type information. Therefore value-level abstraction can be exploited in cases such as previewing an application, where the application's components are dynamically replaced, in the file system where a file representing an unknown type might be stored, and in server environments, where various types could be exchanged between different computers.++Morover, the availability of an existential types for a given protocol is sometimes quite unintuitive. That is, today, a protocol qualifies for an existential type provided that it lacks any `Self` or associated type requirements; however, the associated types of a protocol can be fixed via the same-type constraint. As a result, [post](https://forums.swift.org/t/making-a-protocols-associated-type-concrete-via-inheritance/6557) after [post](https://forums.swift.org/t/constrained-associated-type-on-protocol/38770) has been created asking for this restriction's removal:++```swift+protocol User: Identifiable+  where ID == UUID {+  +  var username: Strng { get }+}+  +let myUsers: [User] ❌+// This is forbidden today+// for no apparent reason.+```++All in all, supporting existential types for all protocols is useful for many situations that involve dynamicity. Not to mention that there are many questions by language users asking about this behavior. Taking everything into consideration, we are confident that addressing this abnormality in the language will build a stronger foundation for [future additions](https://forums.swift.org/t/improving-the-ui-of-generics/22814).+++### Proposed Solution++The constraint prohibiting the use of some protocols as types will be lifted. Consequently, boilerplate code in many projects - especially libraries and frameworks - will be significantly reduced.+++### Detailed Design ++The compiler will no longer differentiate between protocols that don’t have `Self` or associated type requirements and those that do. However, some restrictions will apply to the use of requirements referencing associated types as seen in the below examples.++#### Examples:++##### Protocol with `Self` and Associated Type Requirements ++```swift+protocol Foo {

Would be nice if all examples used the same style (A, B, etc). The ones below do but this one does not for example

filip-sakel

comment created time in a month

more