🍒[5.9][Distributed] Fix handling indirect @in convention params in distributed funcs #67240 #67242
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: This resolves a crash in some projects where the parameter to a distributed func is passed indirect @in on Linux.
Specifically, the following assertion would trigger due to the argument count mismatch: ssert(NextValue + n <= Values.size()); // 3 + 1 <= 3 -> boom (Values expected to be 4 in this particular case)
Seems we never triggered this codepath before, even though many distributed functions with all kinds of parameters were written, they all ended up @in_guaranteed not triggering the bad codepath. Added test reproducing the issue and showcasing that it is fixed now.
Risk: Low, limited to @in passed parameters to distributed funcs which previously would crash
Review by: @xedin @jckarter
Testing: Added CI exercising this code-path, verified in real project with fixed compiler
Original PR: #67240
Radar: rdar://111887706