Pushed as b86e7ae66cb988dda33445c29fa64f93e7ca9c3c

Sorry about the last change, that was the wrong patch.

Thanks for the commits, Aaron. If you don't mind I have a short question: both commits don't seem to list the test cases, have they not been committed at all or are they filtered out in github and/or phabricator? Did I mess something up?

Yes, I was gonna ask somebody else but if you have time, committing this one and https://reviews.llvm.org/D94478 would be nice

And thank you for reviewing my patches :)

Okay, I've added a test and made sure it fails before and succeeds after this patch.

Thanks for the quick review. I've made the requested changes and added a proper commit message. I noticed I forgot that before.

That sounds good but it's different to what this patch is trying to accomplish, isn't it? -ansi already doesn't get passed to the linker.
E.g. with clang 10.0.1 without this patch:

I guess I could add a test for the example I posted, but I'm not sure of how much value that is. Or do you mean a test case that -ansi and -std=c89 behave the same in every situation?

Rebased on lastest main branch and added a few more reviewers from git blame'ing the Options.td file

In D84846#2396303, @MaskRay wrote:

https://fedoraproject.org/wiki/Toolchain/Watermark Seems that .gnu.build.attributes is used with a GCC plugin (annobin?). The feature on its own is probably not that useful. .gnu.linkonce is a proto-comdat legacy feature which the patch should ignore.

In D90457#2390519, @MaskRay wrote:

Is the motivation just to avoid -flto or -flto=lto at link time?

Ping

Add a test that checks that clang accepts -Wa,--generate-missing-build-notes=yes and -Wa,--generate-missing-build-notes=no

I'm looking at this again and I am not sure how it is meant to work. For example in Parser::parseClassSpecifier in ParseDeclCXX.cpp.
Here attrs is a local variable of type ParsedAttributesWithRange, already before my patch. attrs is then passed to

Sorry for taking so long but it seems like I've went down a rabbit hole a bit. My previous patch sets the range in parseGNUAttributes() unconditionally, but that seems to trigger cases such as

Thanks, I'll take a look at the tests.

Updated according to Aaron's comments. I'm not sure about changing the DeclSpec member and moving ParsedAttributesWithRange to ParsedAttr.h.

I know this has been reverted, but for the record, the implementation has a few shortcomings that makes it hard to use it for projects that rely on fallthrough comments:

fallthrough comment detection has been reverted, so abandon this in the meantime.