Skip to content

Conversation

bnbarham
Copy link
Contributor

When compiling with allow errors, it's possible to have invalid
inherited types - both null and ErrorType.

Cleaned up the tests a little - moved the majority of
Frontend/allow-errors.swift into separate files in
Serialization/AllowErrors and use split_file.py instead of #defines.

Resolves rdar://78048470

When compiling with allow errors, it's possible to have invalid
inherited types - both null and ErrorType.

Cleaned up the tests a little - moved the majority of
Frontend/allow-errors.swift into separate files in
Serialization/AllowErrors and use split_file.py instead of #defines.

Resolves rdar://78048470
@bnbarham bnbarham requested review from akyrtzi and xymus May 15, 2021 06:36
@bnbarham
Copy link
Contributor Author

@xymus what are your thoughts on the asserts? Should I add a check for whether compiling with errors or leave as is?

@bnbarham
Copy link
Contributor Author

@swift-ci please test

@xymus
Copy link
Contributor

xymus commented May 17, 2021

Yeah, I think it would be worth taking into account AllowModuleWithCompilerErrors in the asserts. It can prevent us from introducing future unrelated regressions.

@bnbarham
Copy link
Contributor Author

Yeah, I think it would be worth taking into account AllowModuleWithCompilerErrors in the asserts. It can prevent us from introducing future unrelated regressions.

While updating this I realised that addTypeRef already has a null type + error check, so adding another would just be duplicating it.

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.

2 participants