Skip to content

Fix subscript reconstruction #15096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

slavapestov
Copy link
Contributor

Fixes rdar://problem/36132173.

Fixes part of <rdar://problem/36132173>.
Mostly fixes the rest of <rdar://problem/36132173>, but we still
need to correctly reconstruct dependent member types. That's no longer
related to the original problem of subscripts not working though.
@slavapestov slavapestov requested a review from dcci March 9, 2018 02:09
@slavapestov
Copy link
Contributor Author

@dcci Here are the changes we discussed

@slavapestov
Copy link
Contributor Author

@swift-ci Please test

back_inserter(identifier_result._types));
identifier_result._module = decl_scope_result._module;
if (decl_scope_result._decls.size() == 1)
found_univocous = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

This is only used to break out of the earlier loop, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I’m just cargo culting the rest of the code in this function. Not sure I want to spend much time cleaning it up since most of it is going away soon.

Copy link
Contributor

Choose a reason for hiding this comment

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

In that case cargo-cult away, sir!

if (decl_scope_result._decls.empty()) {
result._error = stringWithFormat(
"subscript identifier could not be found by name lookup");
break;
Copy link
Contributor

Choose a reason for hiding this comment

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

If we get to this point do we really want to continue on to the code at line 1303?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See above

@@ -1451,6 +1494,11 @@ static void VisitNodeSetterGetter(
}
}

if (!type_result.HasSingleType()) {
result._error = "bad type";
Copy link
Member

Choose a reason for hiding this comment

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

Do we have a testcase for this case/diagnostic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No. These are invalid cases that should never come up (but maybe if your swiftmodule doesn’t match your debuginfo or something? I don’t know)

Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should worry too much (if we'll ever run across a case where this happens, we can consider adding a test), in particular considering that, as you say, this code might go away in the next while.

@slavapestov slavapestov merged commit b15d007 into swiftlang:master Mar 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants