[CSDiagnostics] Add diagnostics for holes in generic parameter packs #71701

li3zhen1 · 2024-02-17T01:35:49Z

Removed TVO_CanBindToHole flag in ConstraintSystem::openGenericParameter when generic parameter is parameter pack, so that passing nil to generic parameter pack produces fix correctly.

Resolves #69432 .

Before

func foo<each T>(_ bar: repeat each T) { }

foo(nil) // Failed to produce diagnostic for expression; please submit a bug report

After

func foo<each T>(_ bar: repeat each T) { }

foo(1, "hello", 2) // OK

foo(nil) // error: 'nil' requires a contextual type

foo(1, nil) // error: 'nil' requires a contextual type

Diagnostic messages:

/Projects/SwiftPlayground/Sources/main.swift:5:5: error: 'nil' requires a contextual type
foo(nil)
    ^
/Projects/SwiftPlayground/Sources/main.swift:7:8: error: 'nil' requires a contextual type
foo(1, nil)

lib/Sema/ConstraintSystem.cpp

xedin · 2024-02-17T02:25:51Z

One more thing - please add test-cases from description to test/Constraints/variadic_generic_functions.swift and we’d be good to go!

Rajveer100 · 2024-02-20T18:25:07Z

@li3zhen1
Glad to learn from your changes!

xedin · 2024-02-20T19:40:25Z

@li3zhen1 So I've been looking at the the constraint system state with these problematic cases and I'm thinking that we should just produce a tailored fixed for each pack element that cannot be inferred with diagnostic like 'cannot infer pack element # from contextand a tailored version of that when it's converted tonil(that shouldn't be hard to detect because the locator forpack element` is going to have ApplyArgToParam in the path for these cases).

It seems reasonable to let pack element to be bound to a hole and propagate that to the nil type variable instead of other way around because we don't want to attempt binding nil directly until absolutely necessary.

li3zhen1 · 2024-02-20T21:24:23Z

lib/Sema/CSBindings.cpp

+      if (isExpr<NilLiteralExpr>(eltDstLocator->getAnchor())) {
+        ConstraintFix *fix =
+          SpecifyContextualTypeForNil::create(cs, eltDstLocator);
+        return std::make_pair(fix, /*impact=*/(unsigned)10);


I tested this with your fix from #71756 , everything should be good now:

/Users/lizhen/Projects/swift-debug/generic_pack.swift:5:19: error: 'nil' requires a contextual type _ = foo(value: 1, nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:11:34: error: 'nil' requires a contextual type bar(1, 5, "Hello", foo(value: 1, nil), u: 3, w: 4, 8, nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:11:55: error: 'nil' requires a contextual type bar(1, 5, "Hello", foo(value: 1, nil), u: 3, w: 4, 8, nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:19:7: error: 'nil' requires a contextual type _ = S(nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:20:12: error: 'nil' requires a contextual type _ = S.init(nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:22:10: error: 'nil' requires a contextual type _ = S(1, nil) ^ /Users/lizhen/Projects/swift-debug/generic_pack.swift:23:15: error: 'nil' requires a contextual type _ = S.init(2, nil) ^

li3zhen1 · 2024-02-20T21:24:26Z

lib/Sema/CSBindings.cpp

+      }
+
+      // The hole in a generic pack parameter can not be inferred
+      ConstraintFix *fix = SpecifyTypeForPlaceholder::create(cs, eltDstLocator);


I couldn't think of an example that triggers cannot infer pack element # from context, could you name some?

What I was trying to say in my previous comment is that I think we need to add a new ConstraintFix and a new diagnostic to accompany it and record it in TypeVariableBinding::fixForHole when the dstLocator ends with PackElement.

Hi, just added new diagnostics could not infer pack element #%0 from context. But I'm still using unresolved_nil_literal for nil cases. Do we need a new diag for nil?

li3zhen1 · 2024-02-22T16:36:59Z

@li3zhen1 So I've been looking at the the constraint system state with these problematic cases and I'm thinking that we should just produce a tailored fixed for each pack element that cannot be inferred with diagnostic like 'cannot infer pack element # from contextand a tailored version of that when it's converted tonil(that shouldn't be hard to detect because the locator forpack element` is going to have ApplyArgToParam in the path for these cases).

It seems reasonable to let pack element to be bound to a hole and propagate that to the nil type variable instead of other way around because we don't want to attempt binding nil directly until absolutely necessary.

How about this?

/Users/lizhen/Projects/swift-debug/generic_pack.swift:6:15: error: 'nil' requires a contextual type
_ = foo(1, 2, nil)
              ^
/Users/lizhen/Projects/swift-debug/generic_pack.swift:3:20: note: in inferring pack element #3 of 'my_pack_param'
func foo<each T>(_ my_pack_param: repeat each T) {}
                   ^

xedin · 2024-02-22T23:17:52Z

Sorry, I'm trying to decide how I keep about all of the locators manipulation that is going on here.

lib/Sema/ConstraintSystem.cpp

lib/Sema/CSBindings.cpp

lib/Sema/CSDiagnostics.cpp

xedin · 2024-02-27T22:06:33Z

lib/Sema/CSDiagnostics.cpp

+  const auto* locator = getLocator();
+  auto path = locator->getPath();
+
+  if (path.size() > 1) {


The way everything is setup today I don't think you need any of this checking in the path. The fix is always going to be with locator that ends on PackElement and simplifyLocator changes take care of resolving anchor correctly, so I think this whole method could be simplified down to:

auto *locator = getLocator(); auto *elementLoc = locator->castLastElementTo<LocatorPathElt::PackElement>(); if (isExpr<NilLiteralExpr>(getAnchor())) { emitDiagnostic(diag::unresolved_nil_literal); } else { // unable to infer the type of an element of generic pack params emitDiagnostic(diag::could_not_infer_pack_element, elementLoc->getIndex()); } if (auto *applyExpr = getAsExpr<ApplyExpr>(locator->getAnchor())) { // use getCalleeLocator + getOverloadChoice to find overload and note } return true;

func patternInstantiationTupleTest1<each T>() -> (repeat Array<each T>) {} func patternInstantiationConcreteInvalid() { let _: Set<Int> = patternInstantiationTupleTest1() // expected-error@-1 {{cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>'}} let _: (Array<Int>, Set<String>) = patternInstantiationTupleTest1() // expected-error {{'(repeat Array<Int, _>)' is not convertible to '(Array<Int>, Set<String>)', tuples have a different number of elements}} }

Seems like this case in swift/test/Constraints/pack_expansion_types.swift unintentionally hits diag::could_not_infer_pack_element branch without the guarding conditions.

Fixes: [fix: ignore specified contextual type] @ locator@0x1339e7800 [Call@/Users/lizhen/Projects/swift-debug/boldly.swift:4:21 → contextual type] [fix: specify pack element type] @ locator@0x1339e7a68 [Call@/Users/lizhen/Projects/swift-debug/boldly.swift:4:21 → contextual type → tuple type '(/* shape: $T1 */ repeat Array<$T1>)' → tuple type '(_: Set<Int>)' → tuple element #0 → pack element #0] (failed constraint (/* shape: Pack{<<unresolvedtype>>} */ repeat Array<Pack{<<unresolvedtype>>}>) conv Set<Int> @ locator@0x134015400 []) (increasing 'user conversion' score by 1 @ locator@0x134015400 []) (failed constraint (/* shape: Pack{<<unresolvedtype>>} */ repeat Array<Pack{<<unresolvedtype>>}>) bridging conv Set<Int> @ locator@0x134015400 []) /Users/lizhen/Projects/swift-debug/boldly.swift:4:21: error: cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>' let _: Set<Int> = patternInstantiationTupleTest1() ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/lizhen/Projects/swift-debug/boldly.swift:4:21: error: could not infer pack element #0 from context let _: Set<Int> = patternInstantiationTupleTest1() ^

Guess I should add some guards like this?

const auto applyArgToParamElt = (path.end() - 2)->getAs<LocatorPathElt::ApplyArgToParam>(); const auto packElementElt = (path.end() - 1)->getAs<LocatorPathElt::PackElement>(); if (!applyArgToParamElt || !packElementElt) { return false; }

I think that's okay, the conversion fails and the element cannot be inferred because of that. For that particular case we could detect that it's mismatch between collections and propagate the element type down to avoid the second diagnostic.

lib/Sema/ConstraintSystem.cpp

…t overloads and update test cases

…ex in messages

li3zhen1 · 2024-02-28T18:37:11Z

lib/Sema/CSDiagnostics.cpp

Changed to 0-based indexing since I found other sema diagnostics are doing so.

xedin · 2024-02-28T18:39:56Z

lib/Sema/CSDiagnostics.cpp

+  const auto packElementElt =
+      (path.end() - 1)->getAs<LocatorPathElt::PackElement>();
+  if (!applyArgToParamElt || !packElementElt) {
+    return false;


We shouldn't produce a fix in this case because this would just result in a fallback diagnostic this looks like more of an assert to me

For that particular case we could detect that it's mismatch between collections and propagate the element type down to avoid the second diagnostic.

Could you give more hint about this? I'm not sure about how to kick this out:

contextual type → tuple type → tuple type → tuple element #0 → pack element #0

Just so we are on the same page here - you don't have to do it in this PR. This would have to be detected during fixing of the conversion mismatch that's when we have both Set and Array types, we can have a special case in repairFailures for collections

Okay, I'll try to look into this. Just one more question – is this supposed to be a generic type mismatch or the specific case for collections?

This could also invoke the same diagnostics with the same path:

struct S<T> { init() {} } struct S2<T> { init() {} } func patternInstantiationTupleTest1<each T>() -> (repeat S<each T>) {} func patternInstantiationConcreteInvalid() { let _: S2<Int> = patternInstantiationTupleTest1() let _: (S<Int>, S2<String>) = patternInstantiationTupleTest1() }

Hm, maybe it's okay to forward generic arguments upon mismatches in general if the number of expected arguments on the other side matches, so if both types are BoundGenericTypes with the same number of arguments

xedin · 2024-03-01T18:15:57Z

@li3zhen1 We are getting pretty close. I think all we need is to address a few remaining comments and add a few more test-cases that test newly add diagnostic.

li3zhen1 · 2024-03-01T18:58:37Z

@xedin Sorry for the delay. I'm still trying to learn how repairFailure works here. Could you give more hint about this? like do I try avoid the unexpected fixForHole call or just silence the hole's diagnostics?

xedin · 2024-03-01T19:12:37Z

No rush! Regarding repairFailures, there is a simpler problem you can look at which doesn't involve variadic generics:

func test<T>() -> [T] {
  []
}

let _: Set<Int> = test()

xedin · 2024-03-01T19:15:32Z

The failure to convert Array to Set here is "fixed" via IgnoreContextualType fix - (attempting fix [fix: ignore specified contextual type] @ locator@0x14b13f320 [Call@<stdin>:5:19 → contextual type])

This block of code is repairFailures that deals with ContextualType locator could detect that both types are BoundGenericTypes with the same number of arguments and use matchTypes (like we do in other places there) to match them, that would mean that Int from Set is propagated to type variable that opens T of Array and would avoid generic parameter 'T' could not be inferred failure.

xedin · 2024-03-01T19:16:03Z

There should be no <<placeholder>> types in the solution for that expression.

xedin · 2024-03-01T19:16:38Z

But as I mentioned before, you don't have to fix it in this PR - you can just adjust the changed diagnostics, we'll take a look what changed and whether it makes sense.

li3zhen1 · 2024-03-01T19:29:45Z

We shouldn't produce a fix in this case because this would just result in a fallback diagnostic this looks like more of an assert to me

So does this mean that I should move the condition applyArguments -> applyArgToParam -> PackElements to fixForHole like:

  if (dstLocator->isLastElement<LocatorPathElt::PackElement>()) {
    if (applyArguments -> applyArgToParam -> PackElements) {
        // A hole appears as an element of generic pack params
        ConstraintFix *Fix = SpecifyPackElementType::create(cs, dstLocator);
        return std::make_pair(Fix, defaultImpact);
    }
    return std::nullopt;
  }

xedin · 2024-03-01T20:04:41Z

In general if there is a case that cannot be diagnosed, it shouldn't produce a fix just to fail a diagnostic. If we detect that a type variable represents a pack element it shouldn't matter what path it uses because it can always fallback to newly added "cannot infer pack element ..." diagnostic right? In the diagnostic we could check for presence of ApplyArguments or ArgToParam etc. and produce tailored diagnostic messages but the fallback is always there.

li3zhen1 · 2024-03-01T20:20:01Z

If I understand correctly, I need to add the fallback diagnostic, and either:

fix the unexpected <placeholder> first
or allow that case to emit this cannot infer pack element ..., which leads to 2 error at once

Right?

xedin · 2024-03-01T20:55:23Z

Not really, I think check for PackElement can be turned into an assert and check for apply arguments could be removed completely for the diagnostic.

li3zhen1 · 2024-03-01T21:15:10Z

I see. Below is the result accordingly. Guess I can't pass the test without fixing that placeholder?

/Users/lizhen/Projects/swift-projects/build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/bin/swift-frontend /Users/lizhen/Projects/swift-debug/generic_mismatch.swift -typecheck
/Users/lizhen/Projects/swift-debug/generic_mismatch.swift:9:21: error: cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>'
 7 │ func patternInstantiationConcreteInvalid() {
 8 │
 9 │   let _: Set<Int> = patternInstantiationTupleTest1()
   │                     ╰─ error: cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>'
10 │
11 │ }

/Users/lizhen/Projects/swift-debug/generic_mismatch.swift:9:21: error: could not infer pack element #0 from context
 7 │ func patternInstantiationConcreteInvalid() {
 8 │
 9 │   let _: Set<Int> = patternInstantiationTupleTest1()
   │                     ╰─ error: could not infer pack element #0 from context 
                              ❌  this is not expected in test case.
10 │
11 │ }

bool UnableToInferGenericPackElementType::diagnoseAsError() {
  auto *locator = getLocator();
  auto path = locator->getPath();

  const auto packElementElt = (path.end() - 1)->getAs<LocatorPathElt::PackElement>();

  if (isExpr<NilLiteralExpr>(getAnchor())) {
    emitDiagnostic(diag::unresolved_nil_literal);
  } else {
    // ❌ generic mismatch hits here:
    emitDiagnostic(diag::could_not_infer_pack_element,
                   packElementElt->getIndex());
  }

  if (isExpr<ApplyExpr>(locator->getAnchor())) {
    // emit callee side diagnostics
    if (auto *calleeLocator = getSolution().getCalleeLocator(locator)) {
      if (const auto choice = getOverloadChoiceIfAvailable(calleeLocator)) {
        if (auto *decl = choice->choice.getDeclOrNull()) {
          const auto applyArgToParamElt =
              (path.end() - 2)->getAs<LocatorPathElt::ApplyArgToParam>();
          if (auto paramDecl =
                  getParameterAt(decl, applyArgToParamElt->getParamIdx())) {
            emitDiagnosticAt(
                paramDecl->getLoc(), diag::note_in_opening_pack_element,
                packElementElt->getIndex(), paramDecl->getNameStr());
          }
        }
      }
    }
  }

  return true;
}

li3zhen1 · 2024-03-02T00:16:37Z

lib/Sema/CSDiagnostics.cpp

+    if (llvm::any_of(getSolution().Fixes, [&locator](const ConstraintFix *fix) {
+          return fix->getLocator() == locator;
+        }))
+      return false;


Does this make sense?

I'm not sure what are you trying to archive here, this would always return false because locator for diagnostic comes from the fix. What I was saying in my previous comment is that we need

auto packElementElt = locator->getLastElementAs<PackElement>(); assert(packElementElt);

That that's pretty much it.

func patternInstantiationTupleTest1<each T>() -> (repeat Array<each T>) {} func patternInstantiationConcreteInvalid() { let _: Set<Int> = patternInstantiationTupleTest1() // expected-error@-1 {{cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>'}} let _: (Array<Int>, Set<String>) = patternInstantiationTupleTest1() // expected-error {{'(repeat Array<Int, _>)' is not convertible to '(Array<Int>, Set<String>)', tuples have a different number of elements}} }

This case produces 2 fix here:

Fixes: [fix: ignore specified contextual type] @ locator@0x1339e7800 [Call@/Users/lizhen/Projects/swift-debug/boldly.swift:4:21 → contextual type] [fix: specify pack element type] @ locator@0x1339e7a68 [Call@/Users/lizhen/Projects/swift-debug/boldly.swift:4:21 → contextual type → tuple type '(/* shape: $T1 */ repeat Array<$T1>)' → tuple type '(_: Set<Int>)' → tuple element #0 → pack element #0] (failed constraint (/* shape: Pack{<<unresolvedtype>>} */ repeat Array<Pack{<<unresolvedtype>>}>) conv Set<Int> @ locator@0x134015400 []) (increasing 'user conversion' score by 1 @ locator@0x134015400 []) (failed constraint (/* shape: Pack{<<unresolvedtype>>} */ repeat Array<Pack{<<unresolvedtype>>}>) bridging conv Set<Int> @ locator@0x134015400 []) /Users/lizhen/Projects/swift-debug/boldly.swift:4:21: error: cannot convert value of type '(repeat Array<_>)' to specified type 'Set<Int>' let _: Set<Int> = patternInstantiationTupleTest1() ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Users/lizhen/Projects/swift-debug/boldly.swift:4:21: error: could not infer pack element #0 from context let _: Set<Int> = patternInstantiationTupleTest1() ^

I was trying to mute the second fix and it seems work well?

That's fine, let's update the test for now.

It passes tests for now. Is there any thing I need to add?

I understand that it's passing tests but the code is nevertheless wrong and that statement on top of this comment chain has to be removed and tests updated to add new diagnostic.

Updated. Sorry I misunderstood that

xedin · 2024-03-02T01:56:27Z

lib/Sema/CSDiagnostics.cpp

+  auto *locator = getLocator();
+  auto path = locator->getPath();
+
+  auto packElementElt = (path.end() - 1)->getAs<LocatorPathElt::PackElement>();


Nit: We don't actually need to do this arithmetic - use locator->getLastElementAs<LocatorPathElt::PackElement>() instead.

xedin · 2024-03-02T01:57:04Z

test/Constraints/variadic_generic_functions.swift

@@ -1,4 +1,4 @@
-// RUN: %target-typecheck-verify-swift
+// RUN: %target-typecheck-verify-swift -disable-availability-checking


Why is -disable-availability-checking necessary now?

The struct case emit the following error on my end:

/Users/lizhen/Projects/swift-projects/swift/test/Constraints/variadic_generic_functions.swift:107:10: error: unexpected note produced: add @available attribute to enclosing generic struct struct Foo<each T> { ^ /Users/lizhen/Projects/swift-projects/swift/test/Constraints/variadic_generic_functions.swift:107:14: error: unexpected error produced: parameter packs in generic types are only available in macOS 14.0.0 or newer struct Foo<each T> { ^

I removed that flag and placed struct Foo<each T> in test/Constraint/variadic_generic_types.swift now.

xedin · 2024-03-04T19:59:57Z

lib/Sema/CSDiagnostics.cpp

+      if (const auto choice = getOverloadChoiceIfAvailable(calleeLocator)) {
+        if (auto *decl = choice->choice.getDeclOrNull()) {
+          const auto applyArgToParamElt =
+              (path.end() - 2)->getAs<LocatorPathElt::ApplyArgToParam>();


Nit: I think the last thing here - let's use findFirst<LocatorPathElt::ApplyArgToParam>() and check that for presence.

Updated. Thank you!

xedin

Great work, thank you very much!

xedin · 2024-03-04T20:09:19Z

@swift-ci please test

xedin · 2024-03-05T08:30:40Z

@swift-ci please test Windows platform

AnthonyLatsis · 2024-03-06T22:22:29Z

@li3zhen1 Thank you for seeing this through. The next time you wish to take an issue with relatively recent prior activity, please ask the previous volunteers if they are still working on it and mind you taking over. This is not to say someone was actually still working on this particular issue, just something for newcomers to consider — we don’t want good first issues to be a competitive game. Unless otherwise agreed upon by several volunteers 🙂.

li3zhen1 · 2024-03-06T22:38:55Z

@li3zhen1 Thank you for seeing this through. The next time you wish to take an issue with relatively recent prior activity, please ask the previous volunteers if they are still working on it and mind you taking it. We don’t want good first issues to be a competitive game.

Sorry. I’ll keep this in mind.

li3zhen1 · 2024-03-08T00:03:41Z

The failure to convert Array to Set here is "fixed" via IgnoreContextualType fix - (attempting fix [fix: ignore specified contextual type] @ locator@0x14b13f320 [Call@<stdin>:5:19 → contextual type])

This block of code is repairFailures that deals with ContextualType locator could detect that both types are BoundGenericTypes with the same number of arguments and use matchTypes (like we do in other places there) to match them, that would mean that Int from Set is propagated to type variable that opens T of Array and would avoid generic parameter 'T' could not be inferred failure.

@xedin Did you mean that for this case there should be no generic parameter 'T' could not be inferred? I tried swift 5.9 and the main branch and they are all emitting two errors including this. Is this a desired behavior? If so, I feel like it's reasonable to emit 2 errors in the generic pack element case as well.

li3zhen1 requested review from hborla and xedin as code owners February 17, 2024 01:35

xedin reviewed Feb 17, 2024

View reviewed changes

lib/Sema/ConstraintSystem.cpp Outdated Show resolved Hide resolved

xedin mentioned this pull request Feb 20, 2024

[CSSimplify] Adjust isBindable to reject binding if it's directly t… #71756

Merged

li3zhen1 commented Feb 20, 2024

View reviewed changes

li3zhen1 requested a review from slavapestov as a code owner February 21, 2024 01:08

li3zhen1 changed the title ~~Remove TVO_CanBindToHole flag in ConstraintSystem::openGenericParameter when generic parameter is parameter pack~~ [CSSimplify] Add diagnositics for holes in generic parameter packs Feb 22, 2024

li3zhen1 and others added 2 commits February 21, 2024 23:25

[CSDiagnostics] Add diags for holes in generic parameter pack

b44fbf6

[CSDiagnostics] Add diag for holes in generic pack element

a5e04b5

[CSDiagnostics] Add callee side note for holes in generic pack element

9a6d2b5

li3zhen1 force-pushed the my-branch branch from fe9617b to 9a6d2b5 Compare February 22, 2024 17:40

[CSDiagnostics] Update test case for callee side notes

4779ddc

li3zhen1 changed the title ~~[CSSimplify] Add diagnositics for holes in generic parameter packs~~ [CSDiagnostics] Add diagnositics for holes in generic parameter packs Feb 22, 2024

li3zhen1 changed the title ~~[CSDiagnostics] Add diagnositics for holes in generic parameter packs~~ [CSDiagnostics] Add diagnostics for holes in generic parameter packs Feb 22, 2024

xedin reviewed Feb 27, 2024

View reviewed changes

li3zhen1 and others added 3 commits February 27, 2024 20:35

[CSDiagnostics] Update UnableToInferGenericPackElementType to accep…

00b0491

…t overloads and update test cases

Merge branch 'apple:main' into my-branch

e513a7a

[CSDiagnostics] Change error of infer pack element to use 0-based ind…

2be845e

…ex in messages

li3zhen1 commented Feb 28, 2024

View reviewed changes

lib/Sema/CSDiagnostics.cpp

Copy link

Contributor Author

li3zhen1 Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to 0-based indexing since I found other sema diagnostics are doing so.

xedin reviewed Feb 28, 2024

View reviewed changes

Merge branch 'apple:main' into my-branch

9276bb0

li3zhen1 commented Mar 2, 2024

View reviewed changes

li3zhen1 force-pushed the my-branch branch from fb5b9c8 to 84642a6 Compare March 2, 2024 01:28

xedin reviewed Mar 2, 2024

View reviewed changes

[CSDiagnostics] Update test cases for variadic generic functions

1fa5ac4

li3zhen1 force-pushed the my-branch branch from be9bf90 to 1fa5ac4 Compare March 2, 2024 02:11

xedin reviewed Mar 4, 2024

View reviewed changes

[CSDiagnostics] Check applyArgToParamElt for presence

430aa8d

xedin approved these changes Mar 4, 2024

View reviewed changes

xedin merged commit 279e147 into swiftlang:main Mar 6, 2024

		@@ -1,4 +1,4 @@
		// RUN: %target-typecheck-verify-swift
		// RUN: %target-typecheck-verify-swift -disable-availability-checking

[CSDiagnostics] Add diagnostics for holes in generic parameter packs #71701

[CSDiagnostics] Add diagnostics for holes in generic parameter packs #71701

Uh oh!

Conversation

li3zhen1 commented Feb 17, 2024

Before

After

Uh oh!

Uh oh!

xedin commented Feb 17, 2024

Uh oh!

Rajveer100 commented Feb 20, 2024

Uh oh!

xedin commented Feb 20, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

li3zhen1 commented Feb 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xedin commented Feb 22, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xedin Feb 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

li3zhen1 commented Mar 1, 2024

Uh oh!

xedin commented Mar 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

li3zhen1 commented Mar 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

li3zhen1 commented Mar 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xedin commented Mar 1, 2024

Uh oh!

li3zhen1 commented Mar 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

li3zhen1 commented Feb 22, 2024 •

edited

Loading

xedin Feb 28, 2024 •

edited

Loading

xedin commented Mar 1, 2024 •

edited

Loading

li3zhen1 commented Mar 1, 2024 •

edited

Loading

li3zhen1 commented Mar 1, 2024 •

edited

Loading

li3zhen1 commented Mar 1, 2024 •

edited

Loading

li3zhen1 Mar 2, 2024 •

edited

Loading

AnthonyLatsis commented Mar 6, 2024 •

edited

Loading