fix TF-489: stdlib ParseableInterface tests #27971
Merged
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
|
@swift-ci please test tensorflow |
dan-zheng
approved these changes
Oct 30, 2019
|
Those test failures remind me that this is a breaking API change for clients: any code assuming that I think it's an acceptable API breakage because:
I'll run our full toolchain build and downstream client tests on this to make sure we're not unexpectedly breaking anything. |
|
@swift-ci please test tensorflow |
6 similar comments
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
This latest compile error should be simple to fix, but first I'll reproduce it on my local machine so that I'm not just going back and forth for a long time with CI. I expect to send a PR to swift-apis fixing it. |
|
@swift-ci please test tensorflow |
3 similar comments
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow |
|
@swift-ci please test tensorflow macos |
|
Odd, we've got some test failures in seemingly-unrelated tests: Also a test failure in And my full toolchain build reveals that this also causes a swift-apis compile crash: I'll investigate all these problems today. |
I believe this assertion was introduced by #27985, which has not yet been merged. Perhaps this is a red herring? |
Oh yes good point, I made a mistake. I was looking at the results from your build of that PR, not the results of my build of this PR. This PR actually passes toolchain build and tests :) |
…med superclass type It is possible for getSuperclassDecl() to return a non-null type, while getSuperclass() returns an ErrorType. In this case, getContextSubstitutions() could crash because the walk of the superclass chain via getSuperclass() might not find the context class. Instead of crashing in asserts builds, let getContextSubstitutions() silently build an invalid substitution map here, just as it does in no-asserts builds.
|
I believe that #27857 will fix these test failures. I'll cherry-pick that in, run CI, and hopefully finally be able to merge this! |
|
@swift-ci please test tensorflow |
1 similar comment
|
@swift-ci please test tensorflow |
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.
Having
Array.DifferentiableViewonly defined whenElement : Differentiablemakes the compiler quite confused, leading to issues like TF-489, TF-934.This PR works around the issue by making
Array.DifferentiableViewunconstrained.I reduced the problem to something that reproduces on master, and filed an issue for that: SR-11685. Once that issue is resolved, we can try reconstraining it.