- User Since
- Jul 27 2016, 4:23 AM (348 w, 1 d)
Oct 31 2022
@sammccall was there any progress on this so far? This would be really useful to be a clang-tidy check.
Jul 5 2022
Nov 15 2021
True but this is the first change that breaks it.
We're also planning larger build changes after LLVM 14 which will likely disrupt you, see https://lists.llvm.org/pipermail/llvm-dev/2021-October/153238.html.
I think we are getting a bit far, there is time till then to do our adjustments.
Nov 9 2021
Yes, you are correct.
We could make it work, but I'm not sure if we should. The monorepo layout is the only supported one and we've already discussed the plans to remove the non-monorepo layout support to simplify our build.
It would be better to make it work, removing support for the old build system will break many toolchains.
Nov 4 2021
Please let me know if this helps https://drive.google.com/file/d/1nzKVJOnYWuXKH1nJufClXCq5QHeJBlVp/view?usp=sharing
Nov 1 2021
Oct 28 2021
Oct 19 2021
I think this creates a build bustage when llvm is built with the following flags:
Oct 7 2021
Using clang-13, that has this changeset I encounter: clang-13: error: the clang compiler does not support '-march=native'.
Jul 28 2021
I think this introduced a build crash on Firefox. I'm saying this because the build crash occurs in the function touched by this patch, and the yesterday build, that didn't have this patch worked just fine!
Jun 3 2021
You have, with pragma gcc error, look at hb.hh. The problem is that clang has an error dealing with cascading pragma when setting different levels.
Jun 1 2021
I think there is a false positive with this @george.burgess.iv:
In this we have the warning triggered:
mozglue/baseprofiler/core/platform-linux-android.cpp:216:9: error: variable 'r' set but not used [-Werror,-Wunused-but-set-variable]
May 6 2021
May 3 2021
I'm seeing here something very strange, if the user provided copy assignment operator is provided but is = delete and the copy constructor is default this warning will still trigger. Is this something expected?
I'm referring at this issue from the mozilla code-base.
Apr 28 2021
Thank you for this! Also I think it’s very well that you want to implement this warning in clang, with a little bit of more polish it will be up for merger!
Please revert this. This change hasn’t been tested nor reviewed enough. Also I don’t remember seeing this proposed on cfe dev mailing list.
Apr 27 2021
I think this added a regression, where you have this context:
Apr 16 2021
In my case, this will never be true but, because I don't specify LLVM_ENABLE_PROJECTS so the set will not occur.
Apr 12 2021
Add -use-color argument to make it sane with clang-tidy --use-color argument.
Feb 12 2021
This has landed and trunk is already fixed.
Feb 8 2021
Landed in 11.1 https://github.com/llvm/llvm-project/commit/1fdec59bffc11ae37eb51a1b9869f0696bfd5312#diff-2fa23ad0cf1839955ddaf4a0d78a9d9b5fd9b88933f82f6433035916a2655c6c.
Patch needs to be rebased for trunk now.
Feb 4 2021
The failure is wrong.
Feb 3 2021
rebased on 11.1rc2
Jan 30 2021
@tstellar what do you suggest to do here?
Jan 29 2021
Update for plularization of variables name.
Update with format
And there are more issues like: https://github.com/llvm/llvm-project/blob/llvmorg-11.0.1/lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp#L733. old_module_sp_ptr is nowhere declared.
Shouldn't this also update PlatformiOSSimulator.h?
Dec 18 2020
Oct 9 2020
Sep 15 2020
Has been pushed to the 11.x branch https://github.com/llvm/llvm-project/commit/1596c2dfd548b21cf33ad3353882ac465d78c1bb
Jul 2 2020
@njames93 wdyt if we add another parameter to distinguish if we want to use regex or not, and if not we escape the paths?
Also thank you so much for catching this up!
Jun 29 2020
Jun 16 2020
May 19 2020
Let's first see we don't break anything on mozilla.
May 15 2020
Please see https://firefox-source-docs.mozilla.org/code-quality/coding-style/format_cpp_code_with_clang-format.html
@MyDeveloperDay thanks for the patch, I'm gonna run it agains mozilla to see if there is any fallout.
May 12 2020
Sorry, totally forgot about this, thank you!
May 3 2020
As per what @sammccall said.
Apr 28 2020
Just to clarify something here, for me the patch looks good but until I will accept the revision I want to test it on the mozilla codebase.
Apr 27 2020
I've cherry-picked D76850 to 10.x and see if this fixes the issue.
I think we are on the right track with this but what if we are dealing with tok::amp in a context similar to operator const FallibleTArray<E>&(); I can speculate that the outcome will be operator const FallibleTArray<E> &(); which is wrong.
Apr 11 2020
Add release notes.
Apr 10 2020
Feb 24 2020
Feb 5 2020
Yes I have commit access, pushing it directly to 10.x then.
Adding extra comments to the release patch.