Skip to content

[ConstraintSystem] Relax the left-over information check in ComponentStep #38770

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
merged 6 commits into from
Aug 6, 2021

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Aug 5, 2021

Instead of crashing in release builds, let's simply fail the
step and let type-checker produce a fallback diagnostic.

Resolves: rdar://56167233

…tStep`

Instead of crashing in release builds, let's simplify fail the
step and let type-checker produce a fallback diagnostic. Maintain
a trap in debug builds to make it easier to investigate the root
cause of the issue.

Resolves: rdar://56167233
@xedin xedin requested review from hborla and hamishknight August 5, 2021 22:14
@xedin
Copy link
Contributor Author

xedin commented Aug 5, 2021

@hamishknight I have removed redundant check you mentioned and added InvalidState flag to make sure that solving is aborted early and solutions are never produced, this should make sure that solving in release mode always ends up with a fallback diagnostic.

Copy link
Contributor

@hamishknight hamishknight left a comment

Choose a reason for hiding this comment

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

Thanks!

Copy link
Member

@hborla hborla left a comment

Choose a reason for hiding this comment

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

Good idea to produce an error message instead 👍

@hborla
Copy link
Member

hborla commented Aug 6, 2021

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

@hamishknight @hborla After thinking about this some more I think we can drop abort blocks all together because there it would be impossible now to miscompile, WDYT?

…pt to solve should fail

As soon as `InvalidState` flag is set solving of the constraint
system as aborted and all subsequent calls to `solveImpl` would
produce no solutions.
@hborla
Copy link
Member

hborla commented Aug 6, 2021

@xedin Yeah, I think it's fine to always report the error message instead of aborting. If we still want it to crash in this part of the code in a debug build, we could just put in an assert

… state

Setting `InvalidState` already makes sure that there is no possibility
of miscompile.
@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

Adjusted that, for debugging it would print the constraints in question so I just removed NDEBUG blocks.

@hamishknight
Copy link
Contributor

I'd prefer if we crashed in a debug build to make it loud and obvious that we have a logic error, but yeah that could be done with an assert.

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

I think asking to file a bug is loud enough, that would also indicate where the error is better than crash report because not all tools capture stacktraces.

@hamishknight
Copy link
Contributor

Hmm, won't we emit "type of expression is ambiguous without more context" for an expression with no solutions?

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

Ugh, you are right! I have completely forgot about that message assuming that forUndiagnosedError would always result in failed to produce a diagnostic ... message. Fixed now.

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

@swift-ci please smoke test

1 similar comment
@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Aug 6, 2021

@swift-ci please smoke test

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