Don’t crash from circular swift_name attributes #37940
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
If a swift_name attribute’s context referred to the same declaration it was attached to, or a different declaration whose own swift_name referred to the current one, we would recurse infinitely and eventually overflow the stack. This commit makes us instead detect the cycle, diagnose it with a warning, and drop the affected declaration. Fixes rdar://79370809.
|
@swift-ci please smoke test |
|
@CodaFi My impression is that it would be too painful to try to start requestifying here. Do you agree? |
|
‘Long as module loading doesn’t happen on these paths it’ll be gnarly but not impossible. |
|
I've been fiddling with the request evaluator but it's been really finicky, so I'll stick with this implementation for now. |
beccadax
added a commit
to beccadax/swift
that referenced
this pull request
Jul 14, 2021
…ames Don’t crash from circular swift_name attributes
tshortli
added a commit
to tshortli/swift
that referenced
this pull request
Jan 20, 2024
When building the Swift sources of the compiler many of the following warnings
are emitted:
```
.../swift-project/swift/include/swift/AST/Attr.h:3075:10: warning: cycle detected while resolving 'iterator' in swift_name attribute for 'operator=='
bool operator==(iterator x) const { return x.attr == attr; }
^
```
These warnings were implemented in swiftlang#37940
and they indicate that Swift compiler is failing to import a clang decl because
of circular references. Something about the structure of some operator
declarations in C++ headers triggers this warning. I'm not sure what the
correct long term fix for this is, but in the meantime the build log for the
compiler is getting drowned in these warnings which makes it difficult to
notice and find other diagnostics. Since these declarations are getting dropped
instead of imported, we can simply hide them from the Swift compiler in the
first place by guarding the declarations with `#ifdef __swift__`.
tshortli
added a commit
to tshortli/swift
that referenced
this pull request
Jan 20, 2024
When building the Swift sources of the compiler many instances of the following
warning are emitted:
```
.../swift-project/swift/include/swift/AST/Attr.h:3075:10: warning: cycle detected while resolving 'iterator' in swift_name attribute for 'operator=='
bool operator==(iterator x) const { return x.attr == attr; }
^
```
These warnings were implemented in swiftlang#37940
and they indicate that Swift compiler is failing to import a clang decl because
of circular references. Something about the structure of some operator
declarations in C++ headers triggers this warning. I'm not sure what the
correct long term fix for this is, but in the meantime the build log for the
compiler is getting drowned in these warnings which makes it difficult to
notice and find other diagnostics. Since these declarations are getting dropped
instead of imported, we can simply hide them from the Swift compiler in the
first place by guarding the declarations with `#ifdef __swift__`.
carlos4242
pushed a commit
to carlos4242/swift
that referenced
this pull request
May 31, 2024
When building the Swift sources of the compiler many instances of the following
warning are emitted:
```
.../swift-project/swift/include/swift/AST/Attr.h:3075:10: warning: cycle detected while resolving 'iterator' in swift_name attribute for 'operator=='
bool operator==(iterator x) const { return x.attr == attr; }
^
```
These warnings were implemented in swiftlang#37940
and they indicate that Swift compiler is failing to import a clang decl because
of circular references. Something about the structure of some operator
declarations in C++ headers triggers this warning. I'm not sure what the
correct long term fix for this is, but in the meantime the build log for the
compiler is getting drowned in these warnings which makes it difficult to
notice and find other diagnostics. Since these declarations are getting dropped
instead of imported, we can simply hide them from the Swift compiler in the
first place by guarding the declarations with `#ifdef __swift__`.
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.
If a swift_name attribute’s context referred to the same declaration it was attached to, or a different declaration whose own swift_name referred to the current one, we would recurse infinitely and eventually overflow the stack. This commit makes us instead detect the cycle, diagnose it with a warning, and drop the affected declaration.
Fixes rdar://79370809.