This patch is to avoid attaching the calling convention attribute to the result type if this attribute was ignored and calling convention was substituted by default.
Details
- Reviewers
aaron.ballman rnk rsmith - Commits
- rGf49c0f83aa48: Fix assertion "Chunk.Kind == DeclaratorChunk::Function" with attributed type.
rC260373: Fix assertion "Chunk.Kind == DeclaratorChunk::Function" with attributed type.
rL260373: Fix assertion "Chunk.Kind == DeclaratorChunk::Function" with attributed type.
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/clang/Sema/Sema.h | ||
---|---|---|
2938 ↗ | (On Diff #42284) | Rather than adding this extra entry point, I think it would be simpler to extend CheckCallingConvAttr to return whatever extra info we need. Besides, this new entry point also emits diagnostics, and it has a name that suggests it will not emit diagnostics. |
lib/Sema/SemaType.cpp | ||
5866 ↗ | (On Diff #42284) | Right, we've already done the work that you are doing down below. We should just get what we needed to know out of here and pass it on. |
5925–5926 ↗ | (On Diff #42284) | At a high level, why would you want to not create an AttributedType here? That seems desirable, the user wrote the type attribute in the source, and that should be reflected in the AST sugar. If adding this sugar causes assertions later, then the bug must be somewhere else. |
test/CodeGen/adding_defaulted_attr_to_type.c | ||
5 ↗ | (On Diff #42284) | You can add more tests. I noticed this crashes for me: void (__attribute__((regparm(2), stdcall)) foo)(int); That seems like a good one to add. You can also rerun the test with i686-unknown-linux-gnu and #ifdefs to see that we accept the convention as desired on 32-bit. |
I've updated the patch. Please, re-review it again.
About creating attributed type - I think we shouldn't create it if we ignored specified CC attribute. Ignoring specified CC attribute (and emitting the warning, of course) leads to substituting it by default; calling convention, substituted by default, is the same situation like there is no CC attribute specified for chosen function. Thus, from this point of view, we should not create AttributedType.
I tend to agree with @rnk on this -- it is a shame to lose that syntactic information in the AST representation (for instance, tools may wish to detect the presence of that attribute in the source to perform different analyses on the type). Even if it is semantically ignored, it is still something the user wrote. For instance, this means we cannot round-trip the user's source code through pretty printing, despite the code not being ill-formed.
test/CodeGen/adding_defaulted_cc_attr_to_type.c | ||
---|---|---|
1 ↗ | (On Diff #43442) | Can you drop the svn props on the file? Our convention is to not rely on props, but instead save the file with UNIX line endings. |
I've updated the patch. Now, I've updated the function unwrapping mechanism to work properly with AttributedType.
Please, re-review the patch.