Page MenuHomePhabricator
Feed Advanced Search

Sat, Sep 10

Codesbyusman updated the diff for D133194: rewording note note_constexpr_invalid_cast.

updating with the suggested changes.

Sat, Sep 10, 10:55 AM · Restricted Project, Restricted Project
Codesbyusman added a comment to D133194: rewording note note_constexpr_invalid_cast.

updated, I am not getting why this is happening but in the .cpp test file without Wvla all is working and is detecting by default as you are saying but when I use vla-warning/note it gives me error that "warning seen but not expected"

It's because we're passing -pedantic on all three RUN lines; because the file is a C++ source file, we issue the pedantic "you're using an extension" warning: https://godbolt.org/z/a8nv6dhE5 so the -Wvla is redundant after all (sorry for not catching that sooner).

Sat, Sep 10, 10:30 AM · Restricted Project, Restricted Project

Fri, Sep 9

Codesbyusman updated the diff for D133194: rewording note note_constexpr_invalid_cast.

updated, I am not getting why this is happening but in the .cpp test file without Wvla all is working and is detecting by default as you are saying but when I use vla-warning/note it gives me error that "warning seen but not expected"

Fri, Sep 9, 1:01 PM · Restricted Project, Restricted Project
Codesbyusman added inline comments to D133194: rewording note note_constexpr_invalid_cast.
Fri, Sep 9, 12:43 PM · Restricted Project, Restricted Project
Codesbyusman added inline comments to D133194: rewording note note_constexpr_invalid_cast.
Fri, Sep 9, 12:35 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D133194: rewording note note_constexpr_invalid_cast.

updating test

Fri, Sep 9, 11:06 AM · Restricted Project, Restricted Project
Codesbyusman added inline comments to D133194: rewording note note_constexpr_invalid_cast.
Fri, Sep 9, 11:03 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D133194: rewording note note_constexpr_invalid_cast.

updating one time again, to again run test as no failed test on my system.

Fri, Sep 9, 10:37 AM · Restricted Project, Restricted Project
Codesbyusman added a comment to D133194: rewording note note_constexpr_invalid_cast.

Hi,
I am not getting why Sema/cast.c is failing here. While all test are running fine on my system?

Fri, Sep 9, 10:00 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D133194: rewording note note_constexpr_invalid_cast.

updated the test work for the patch

Fri, Sep 9, 7:53 AM · Restricted Project, Restricted Project

Sep 2 2022

Codesbyusman updated the summary of D133194: rewording note note_constexpr_invalid_cast.
Sep 2 2022, 3:15 AM · Restricted Project, Restricted Project
Codesbyusman requested review of D133194: rewording note note_constexpr_invalid_cast.
Sep 2 2022, 3:11 AM · Restricted Project, Restricted Project

Aug 26 2022

Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated.

Aug 26 2022, 2:48 AM · Restricted Project, Restricted Project

Aug 25 2022

Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated

Aug 25 2022, 8:51 AM · Restricted Project, Restricted Project

Aug 24 2022

Codesbyusman added inline comments to D131683: Diagnosing the Future Keywords.
Aug 24 2022, 6:01 PM · Restricted Project, Restricted Project
Codesbyusman added inline comments to D131683: Diagnosing the Future Keywords.
Aug 24 2022, 4:01 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated test cases and suggestions.

Aug 24 2022, 3:55 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated with suggestions and test cases.

Aug 24 2022, 3:41 AM · Restricted Project, Restricted Project

Aug 22 2022

Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated with suggestios

Aug 22 2022, 2:28 PM · Restricted Project, Restricted Project

Aug 19 2022

Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated.

Aug 19 2022, 6:33 AM · Restricted Project, Restricted Project

Aug 17 2022

Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated test cases.

Aug 17 2022, 12:04 PM · Restricted Project, Restricted Project
Codesbyusman added a comment to D130510: Missing tautological compare warnings due to unary operators.

working on the test. Will update the patch soon.

Aug 17 2022, 7:27 AM · Restricted Project, Restricted Project

Aug 16 2022

Codesbyusman updated the diff for D131683: Diagnosing the Future Keywords.

updated.

Aug 16 2022, 1:35 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated.

Aug 16 2022, 10:33 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated.

Aug 16 2022, 10:05 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated.

Aug 16 2022, 6:46 AM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated also the test cases.

Aug 16 2022, 6:44 AM · Restricted Project, Restricted Project

Aug 15 2022

Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updates

Aug 15 2022, 1:53 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updating for the missing tautological compare warnings.

Aug 15 2022, 1:49 PM · Restricted Project, Restricted Project

Aug 11 2022

Codesbyusman added inline comments to D131683: Diagnosing the Future Keywords.
Aug 11 2022, 7:58 AM · Restricted Project, Restricted Project
Codesbyusman retitled D131683: Diagnosing the Future Keywords from "Diagnosing the Future Keywords" to Diagnosing the Future Keywords.
Aug 11 2022, 7:44 AM · Restricted Project, Restricted Project
Codesbyusman requested review of D131683: Diagnosing the Future Keywords.
Aug 11 2022, 7:39 AM · Restricted Project, Restricted Project

Aug 3 2022

Codesbyusman added a comment to D130510: Missing tautological compare warnings due to unary operators.

Can you add my earlier test case or something like it to SemaCXX/warn-bitwise-compare.cpp ?

template <int I, class T>
void foo(int x) {
    bool b1 = (x & sizeof(T)) == 8;
    bool b2 = (x & I) == 8;
    bool b3 = (x & 4) == 8;  // only warn here
}

void run(int x) {
    foo<4, int>(8);
}
Aug 3 2022, 9:34 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

Adopted another approach working for the error caught. Kindly review this.

Aug 3 2022, 1:45 PM · Restricted Project, Restricted Project

Jul 28 2022

Codesbyusman added a comment to D130510: Missing tautological compare warnings due to unary operators.

LGTM! I'll make some editorial corrections for grammar to the release note when I land.

Jul 28 2022, 4:51 AM · Restricted Project, Restricted Project

Jul 27 2022

Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updated with the small fixes and addition of release note

Jul 27 2022, 1:09 PM · Restricted Project, Restricted Project
Codesbyusman added a comment to D130510: Missing tautological compare warnings due to unary operators.

Thank you for this, I think this is good incremental progress and is almost ready to go. Just a few small nits, but also, can you also add a release note for the fix (be sure to mention which issue is being closed too).

Note, the precommit CI failures are unrelated to the changes in this patch.

Jul 27 2022, 12:00 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updating the code suggestions and test cases.

Jul 27 2022, 8:42 AM · Restricted Project, Restricted Project

Jul 26 2022

Codesbyusman added inline comments to D130510: Missing tautological compare warnings due to unary operators.
Jul 26 2022, 11:02 AM · Restricted Project, Restricted Project

Jul 25 2022

Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

also updating for the Xor bitwise operator

Jul 25 2022, 1:37 PM · Restricted Project, Restricted Project
Codesbyusman updated the diff for D130510: Missing tautological compare warnings due to unary operators.

updating to more efficient

Jul 25 2022, 12:48 PM · Restricted Project, Restricted Project
Codesbyusman retitled D130510: Missing tautological compare warnings due to unary operators from updating the function for the tautological warnings for the unary operators to Missing tautological compare warnings due to unary operators.
Jul 25 2022, 12:43 PM · Restricted Project, Restricted Project
Codesbyusman removed a reviewer for D130510: Missing tautological compare warnings due to unary operators: NoQ.
Jul 25 2022, 12:38 PM · Restricted Project, Restricted Project
Codesbyusman removed a reviewer for D130510: Missing tautological compare warnings due to unary operators: NoQ.
Jul 25 2022, 12:37 PM · Restricted Project, Restricted Project
Codesbyusman removed a reviewer for D130510: Missing tautological compare warnings due to unary operators: NoQ.
Jul 25 2022, 12:37 PM · Restricted Project, Restricted Project
Codesbyusman requested review of D130510: Missing tautological compare warnings due to unary operators.
Jul 25 2022, 12:36 PM · Restricted Project, Restricted Project

Jul 24 2022

Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

updated the libcxx all files

FYI for libcxx you can ignore the red format CI step. So the libcxx build is green :-)

I had a look at your libc++ changes and they look good, thanks.
So LGTM for the libc++ part.

Jul 24 2022, 1:04 PM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updated the libcxx all files

Jul 24 2022, 10:10 AM · Restricted Project, Restricted Project, Restricted Project

Jul 22 2022

Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updated libcxx ready to check again

Jul 22 2022, 11:06 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updating of the libcxx with the regex in the diagnostic messages, haven't test them yet locally

Jul 22 2022, 9:47 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman reopened D129048: Rewording the "static_assert" to static assertion.
Jul 22 2022, 9:00 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

Jul 22 2022, 9:00 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.)

Yes, exactly. It's always possible to write tests that depend on implementation details of another component in subtle ways, and the fact that such brittle tests exist doesn't create a responsibility on that component to avoid breaking those downstream users. Here, it's about Clang making a valid change and libc++ containing brittle tests, but it happens quite often where libc++ changes something valid and a downstream consumer is broken in some way. The LLVM revert culture has some benefits to keep things working in a post-commit CI world, however I've noticed that it also creates a lot of friction between projects and sometimes makes important work much more difficult to land than it should. For example, we're currently in the middle of D128146 where LLDB reverted an important patch for LLVM 15 because one of their tests broke. This is not something that comes up super often, but it's extremely disruptive and frustrating when it does, and I think it would be worth trying to address. Anyway, I'm digressing now, but I'll try to talk to a few people at the LLVM Dev Meeting to see if this is a shared concern and to think about potential solutions to address this.

That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

Agreed.

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help?

Replacing static_assert by (static_assert|static assertion) should do the trick. See the patch attached to this comment, I think it should satisfy the CI @Codesbyusman.

I just want to say: I really appreciate the insight you gave into the libc++ testing in this thread. From the CFE's perspective, our view of precommit is "it is basically always misconfigured or broken in some way", so knowing that you guys keep yours running well is nice to hear! We'll be more cognizant in the future.

I DO think there IS a sizable difference between patches like this one, and patches like my deferred-concepts (which, btw, the libc++ tests have been great for coming up with new tests... though it was a pain to figure out how to run them in the first place!). My patches DID deserve the reverts it received so far, so don't see Aaron's mention as an issue with that.

I appreciate your suggestion/patch file, that IS a much better regex than we'd come up with, and looks like it should work. So thank you! We'll commit that once @Codesbyusman can get it integrated into his patch (and we'll make sure CI passes too!).

Jul 22 2022, 8:57 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

The libc++ CI runs pre-commit only, and it runs on all commits that touch something under libcxx/, libcxxabi/, runtimes/ and libunwind/. In particular, it won't trigger if you make changes to clang/ only -- that would create too much traffic and concretely it wouldn't help much, as we're rarely broken by Clang changes (this is an exception). Once the tests under libcxx/ were touched, the libc++ CI triggered, I found this build for instance: https://buildkite.com/llvm-project/libcxx-ci/builds/12210. I do think it boils down to familiarity -- while the Clang pre-commit CI is sometimes overlooked because it fails spuriously, the libc++ CI usually doesn't, so when it fails, there's usually a good reason. I do understand why someone mostly familiar with the Clang workflow could think they needed to be overlooked, though.

Thanks for the explanation!

FWIW, the specific reason why I overloooked it was because of running against old versions of Clang -- I saw the diagnostic was correct in the test and presumed that the old clang was a bot configuration issue. It definitely doesn't help that Clang's precommit CI tends to be spuriously broken quite often; it's trained some of us reviewers to be more dismissive of failing precommit CI than we should.

Concretely, libc++ supports the two latest releases of Clang, and so the CI tests against those. In fact, we run most of the tests using pre-installed Clangs since it allows us to bypass building Clang itself, which is a necessary optimization in the current setup. Regarding the tests themselves, I am able to find the following kind of output in the CI job that failed:

Yeah, which makes a lot of sense for libc++!

FAIL: llvm-libc++-shared.cfg.in :: std/numerics/numbers/illformed.verify.cpp (4388 of 7532)
[...]
error: 'error' diagnostics expected but not seen:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line * (directive at /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/libcxx/test/std/numerics/numbers/illformed.verify.cpp:15): static assertion failed{{.*}}A program that instantiates a primary template of a mathematical constant variable template is ill-formed.
error: 'error' diagnostics seen but not expected:
  File /home/libcxx-builder/.buildkite-agent/builds/2b1c77dd9e90-1/llvm-project/libcxx-ci/build/generic-cxx2b/include/c++/v1/numbers Line 83: static_assert failed due to requirement '__false<int>' "A program that instantiates a primary template of a mathematical constant variable template is ill-formed."
2 errors generated.

IMO this is reasonable output, in fact it's pretty much as good as we could have had. So I'm not taking any action item regarding improving the output of our CI, but I'm entirely open to suggestions if somebody has some.

I don't have a concrete suggestion for the CI output itself -- the failure was clear in retrospect, this was more a matter of not being familiar with the testing practices used.

At a high-level, I think it boils down to familiarity. If we can get the libc++ CI to run as part of precommit CI (assuming precommit CI can be made to run with reliable results, which is a bit of a question mark),

It is pretty reliable. However, I don't think it'll ever become reasonable to run the full libc++ CI on every Clang patch due to resource limitations.

The resource limitations are certainly a pragmatic thing for us to be concerned with, but I hope we're able to find some happy middle ground.

It would have also helped to catch the cause for the initial revert where everyone thought the patch was ready to land.

100% agreed, however this is blocked on the resource limitations mentioned above. I guess one thing we could do here is trigger a simple bootstrapping build of Clang and run the libc++ tests in a single configuration even on changes to clang/. That might catch most issues and perhaps that would be small enough to be scalable. I'll experiment with that after the release.

Thanks, that would be really beneficial. It's not just diagnostic wording changes that cause Clang developers problems with libc++ reverts; I've also seen C++20 work reverted because it broke libc++ without anyone in Clang knowing about it until after it landed (most recently, it's with the deferred concept checking work done by @erichkeane).

Another thing that would help would be to get the libc++ test bots into the LLVM lab (https://lab.llvm.org/buildbot/#/builders)

Libc++ CI is pre-commit, the lab is post-commit only AFAICT.

Correct, but right now we have no community testing for libc++ whatsoever from the perspective of Clang folks. We only find out about failures when libc++ folks start reverting or pointing them out.

I also don't know whether there's a way to bridge between BuildKite and BuildBot, and what that would look like. So while I share the desire to have a single place to look for all LLVM wide CI, I'm not sure it is possible given the variety of technologies used.

I don't know enough about the technology to know if it's easy or hard, unfortunately.

and ensure that they're sending failure emails to everyone on the blame list including people who land a patch on behalf of others.

100% agreed here -- this is one problem with our current setup.

It looks like we have one builder for libc++, but it doesn't appear to be working recently: https://lab.llvm.org/buildbot/#/builders/156.

Yeah, this one needs to be removed, it's a remnant of when we used to have libc++ CI on BuildBot.

Okay, so to summarize:

  1. I'll experiment with a simple job that runs the libc++ pre-commit CI on every patch to Clang. We'll see if that scales.

Thanks, that would be awesome if it works out!

  1. I'll look into sending blame emails from the ongoing (every 3h) job that runs the whole libc++ CI. This is basically equivalent to the buildbot functionality and it's arguably something that we're missing here. I have no idea how to do that, though, but it must be possible.

Thank you!!

  1. Usually, for these types of failures, we actually notice and fix it on our end without requesting a revert. For this kind of change, my opinion is that the burden of fixing the code should have been on us, kind of like when the LLDB data formatters break because we made a totally legal change in libc++. Nobody jumped in to fix it on the libc++ side this time because (I assume) we're racing for the release, but normally I or someone else would have chimed in to fix this without annoying Clang.

FWIW, I've convinced myself that I agree with you here that the burden probably should have been on libc++ maintainers in this case. libc++ almost feels more like a downstream consumer of Clang in terms of testing needs, so I think when tests break because Clang diagnostic wording or behavior changes in a standards conforming way, libc++ folks should address it, but if Clang changes in a way that's not standards conforming, then Clang folks should address it. (Roughly speaking.) That said, I absolutely think we all need to continue to collaborate closely with one another as best we can when issues arise, and I really appreciate the discussion on how we can do that!

For this particular issue, I'd like @Codesbyusman to continue to try to fix the libc++ testing issues (it's good experience), but if that takes significantly longer (say, more than 8 hours of his effort), perhaps @ldionne or someone else from libc++ will have a moment to step in to help? (For reference, Usman is a Google Summer of Code mentee and this was his first patch for Clang. I think this has been a really good way for him to see how open source collaborations work in practice but I also don't want him to get bogged down too much if I can help it. Normally I'd step in to help directly, but I've been in WG14 meetings all week and so I am pretty swamped at the moment.)

Jul 22 2022, 8:55 AM · Restricted Project, Restricted Project, Restricted Project

Jul 19 2022

Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

the libcxx updates but not tested. working on them

I just run the check-cxx on local system. It seems to pass all testcases after applying the current patch.

Testing Time: 2147.75s

Unsupported      :  307
Passed           : 7184
Expectedly Failed:   41
Jul 19 2022, 9:49 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

the libcxx updates but not tested. working on them

Jul 19 2022, 7:36 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129014: rewording static_assert to more generic static assertion.

*ERR_CLOSED: <differential.updaterevision> This revision has already been
closed*

Jul 19 2022, 7:15 AM · Restricted Project, Restricted Project
Codesbyusman abandoned D130085: libcxx changes not tested yet. Testing them..
Jul 19 2022, 7:07 AM · Restricted Project, Restricted Project
Codesbyusman requested review of D130085: libcxx changes not tested yet. Testing them..
Jul 19 2022, 7:01 AM · Restricted Project, Restricted Project

Jul 13 2022

Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

ok. I will take care of this next time. Thank you.

Jul 13 2022, 12:09 PM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

Please format your patch with clang-format. See the command at the end of this: https://clang.llvm.org/docs/ClangFormat.html

git diff -U0 --color=never | clang-format-diff.py -i -p1

Jul 13 2022, 11:26 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

run the clang-format

Jul 13 2022, 11:25 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated subscribers of D129048: Rewording the "static_assert" to static assertion.

Done.

Jul 13 2022, 10:39 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updating new lines

Jul 13 2022, 10:34 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added inline comments to D129048: Rewording the "static_assert" to static assertion.
Jul 13 2022, 10:25 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updated the format issues

Jul 13 2022, 10:17 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updated the comment styles suggested

Jul 13 2022, 9:39 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

the tests for the coverage of changes being made for the static assertion

Jul 13 2022, 8:43 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

I think this is getting pretty close! I did have some style guideline changes, and at least one test addition I'd like to see though. Also, it looks like precommit CI caught a test that still needs to be updated:

FAIL: Clang :: SemaCXX/cxx98-compat.cpp (16448 of 68726)

******************** TEST 'Clang :: SemaCXX/cxx98-compat.cpp' FAILED ********************

Script:

--

: 'RUN: at line 1';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++11 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp

: 'RUN: at line 2';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++14 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT

: 'RUN: at line 3';   /var/lib/buildkite-agent/builds/llvm-project/build/bin/clang -cc1 -internal-isystem /var/lib/buildkite-agent/builds/llvm-project/build/lib/clang/15.0.0/include -nostdsysteminc -fsyntax-only -std=c++17 -Wc++98-compat -verify /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp -DCXX14COMPAT -DCXX17COMPAT

--

Exit Code: 1



Command Output (stderr):

--

error: 'warning' diagnostics expected but not seen: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: static_assert declarations are incompatible with C++98

error: 'warning' diagnostics seen but not expected: 

  File /var/lib/buildkite-agent/builds/llvm-project/clang/test/SemaCXX/cxx98-compat.cpp Line 155: 'static_assert' declarations are incompatible with C++98

2 errors generated.



--



********************
Jul 13 2022, 7:10 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updated the styles and other small things

Jul 13 2022, 7:06 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

the parser updates maked for the static asserion

Jul 13 2022, 4:02 AM · Restricted Project, Restricted Project, Restricted Project

Jul 5 2022

Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

Yes I am looking into the DiagnosticParseKinds.td. Kindly also look another error encountered in testing while updating the test. Although not having in my system but this is giving .
Look here

Jul 5 2022, 9:12 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman added a comment to D129048: Rewording the "static_assert" to static assertion.

Yes I am looking into the DiagnosticParseKinds.td

Jul 5 2022, 9:07 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updating the test files for the last update

Jul 5 2022, 7:22 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updating some to the back strings becaue the orginal were more better

Jul 5 2022, 6:22 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

new changes as required -- final

Jul 5 2022, 1:25 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

update

Jul 5 2022, 1:07 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

all

Jul 5 2022, 12:40 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

all changes in one patch revision

Jul 5 2022, 12:33 AM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

All changes in one place

Jul 5 2022, 12:31 AM · Restricted Project, Restricted Project, Restricted Project

Jul 4 2022

Codesbyusman updated the summary of D129048: Rewording the "static_assert" to static assertion.
Jul 4 2022, 11:58 PM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

updating

Jul 4 2022, 11:35 PM · Restricted Project, Restricted Project, Restricted Project
Codesbyusman updated the diff for D129048: Rewording the "static_assert" to static assertion.

Updating the files as required

Jul 4 2022, 11:29 PM · Restricted Project, Restricted Project, Restricted Project

Jul 3 2022

Codesbyusman abandoned D129014: rewording static_assert to more generic static assertion.
Jul 3 2022, 11:00 AM · Restricted Project, Restricted Project
Codesbyusman requested review of D129048: Rewording the "static_assert" to static assertion.
Jul 3 2022, 10:59 AM · Restricted Project, Restricted Project, Restricted Project

Jul 1 2022

Codesbyusman updated subscribers of D129014: rewording static_assert to more generic static assertion.

Ok ... I am working on the tests I will update it

Jul 1 2022, 9:07 PM · Restricted Project, Restricted Project
Codesbyusman added reviewers for D129014: rewording static_assert to more generic static assertion: aaron.ballman, erichkeane, xgupta.
Jul 1 2022, 1:25 PM · Restricted Project, Restricted Project
Codesbyusman requested review of D129014: rewording static_assert to more generic static assertion.
Jul 1 2022, 1:21 PM · Restricted Project, Restricted Project

Jun 14 2022

Codesbyusman added inline comments to D127759: [Diagnostic] Clarify -Winfinite-recursion message.
Jun 14 2022, 12:28 PM · Restricted Project, Restricted Project
Codesbyusman requested review of D127759: [Diagnostic] Clarify -Winfinite-recursion message.
Jun 14 2022, 8:59 AM · Restricted Project, Restricted Project