[SILGen] Don't crash when calling a generic init with default args. #7169
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In cases where a default value is used for a parameter with generic type, the argument list might be empty. In that case, we don't need to emit any arguments!
|
@swift-ci Please test |
|
Why is this specific to generic arguments? |
|
Why didn't this happen when calling things other than initializers? I think this warrants further investigation. |
|
That's fair, but I'm not qualified to do it. Want a Radar? |
|
What was the actual crash you saw? |
|
|
Really I'm just trying to get #7156 in, because this isn't a regression. :-/ |
|
That looks like something is not lining up. We should not be claiming a parameter if we don't need to. Go ahead and file a JIRA and assign it to me, I need to rework that code some time soon for generic subscripts anyway. |
|
Mmk. What do you want me to do for now? Land this because it fixes a crash? Or take the problematic test case out of #7156 for now? |
|
Filed SR-3808. |
|
I think landing this for now is OK |
|
All right. Thanks for the review, and the push to file the follow-up bug! |
|
I agree, FWIW, this looks like a reasonable spot fix for 3.1. |
jrose-apple
added a commit
to jrose-apple/swift
that referenced
this pull request
Feb 1, 2017
…wiftlang#7169) In cases where a default value is used for a parameter with generic type, the argument list might be empty. In that case, we don't need to emit any arguments!
tkremenek
pushed a commit
that referenced
this pull request
Feb 1, 2017
…ed initializer (#7171) * [SILGen] Don't crash when calling a generic init with default args. (#7169) In cases where a default value is used for a parameter with generic type, the argument list might be empty. In that case, we don't need to emit any arguments! * Fix ParameterList::clone to handle deserialized defaults arguments. (#7156) It was checking the wrong predicate, and therefore failing to mark inherited default arguments as actually being inherited. While here, explicitly clear out default arguments from non-inherited cloned parameter lists. I don't think this case can come up today, but it's better to be correct when we do hit it. rdar://problem/30167924
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In cases where a default value is used for a parameter with generic type, the argument list might be empty. In that case, we don't need to emit any arguments!
Fixes a crash that came up when writing test cases for #7156.