[Sema] Skip adding solutions to completion callback if needed

[bnbarham]

If CompletionContextFinder fails to find a CompletionNode, skip trying to filter and add solutions to the completion callback. This prevents an assertion/crash in filterSolutionsForCodeCompletion which assumes CompletionNode is non-null (either an expression or keypath).

Resolves rdar://99966094.

[bnbarham]

@swift-ci please test

[xedin]

I see. The example here could be a function with multiple result builder arguments and code completion token located in the second one, right @ahoppen?

[bnbarham]

@swift-ci please test macOS platform

[ahoppen]

I don’t think suppressing the assertion is the correct fix here. If we can’t find the code completion context, there’s something fundamentally going wrong and I’d like to figure out what it is.

Also, you removed a few assertions that we are in a key path completion context where a few lines below, we are getting the key path completion component, which is pretty much guaranteed to cause issues down the line.

[bnbarham]

I don’t think suppressing the assertion is the correct fix here. If we can’t find the code completion context, there’s something fundamentally going wrong and I’d like to figure out what it is.

The other location filterSolutionsForCodeCompletion is called has:

  // If there was no completion expr (e.g. if the code completion location was
  // among tokens that were skipped over during parser error recovery) bail.

and so I was assuming there was a similar case here. If that's not the case and we should always have a context here then IMO we should add an assertion before the if (and keep the if so that only +Asserts fails). I'd rather bail here in the release case than crash.

Also, you removed a few assertions that we are in a key path completion context where a few lines below, we are getting the key path completion component, which is pretty much guaranteed to cause issues down the line.

These were just superfluous, the same assertion is in getKeyPathContainingCompletionComponent which is called directly after anyway.