- User Since
- Jul 12 2018, 4:43 PM (207 w, 5 d)
May 18 2022
You might also mention that this solves #54716 (in my understanding).
Looks good to me.
May 16 2022
May 14 2022
May 13 2022
So we have overloads
Hmm, didn't see this on Linux. I'll try to disambiguate.
May 12 2022
Unify Argument types and parsing. Add AST test. Simplify TableGen.
May 11 2022
Add an AST test to check that we parse the arguments correctly. (We don't use them for diagnostics currently.)
May 9 2022
May 6 2022
Add a release note.
Use 1 instead of 0 just to be sure. We don't want to trigger warnings about division by zero.
Also consider ++ and -- as writing, test all operators.
May 5 2022
May 4 2022
@rupprecht, do you still do integration at Google? This patch might be interesting to try out, since it strengthens some warnings.
Apr 29 2022
Apr 28 2022
Ok, that's a valid point.
Also I still don't understand what specifically this is fixing. What exactly was wrong about the previous configuration?
Fair enough, but don't we want to enforce LF or CRLF, respectively? An editor could inadvertently change the line endings, and someone might not notice before committing. Explicitly specifying the right line endings gives us the proper line endings even if some editors mess things up.
I think this change broke again what D97625 was trying to fix. These are text files and we want them to keep the specified line endings regardless of the local git configuration. See also @smeenai's comment D124563#3478625.
As a temporary workaround for switching between branches, just add a local file clang-tools-extra/test/clang-apply-replacements/.gitattributes with contents:
Inputs/crlf/crlf.cpp binary Inputs/crlf/crlf.cpp.expected binary
This will remove all kinds of filtering for the moment. When you remove that file, just make sure to force checkout both files again to make sure the filter applies.
Apr 27 2022
Ok, let's do it this way.
Would be nice if someone could accept this. I think this comes closest to the intention of D97625.
Drop * text=auto, so that we renormalize only the files that need it.
Most of the files changed here are not affected by the .gitattributes file, such as
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/readability-duplicate-include.h clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/readability-duplicate-include2.h clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-duplicate-include/system/sys/types.h clang-tools-extra/test/clang-tidy/checkers/readability-else-after-return-if-constexpr.cpp clang-tools-extra/test/modularize/Inputs/CompileError/module.modulemap clang-tools-extra/test/modularize/Inputs/MissingHeader/module.modulemap clang-tools-extra/test/pp-trace/Inputs/module.map
The only affected files seem to be
Apr 26 2022
This looks pretty good!
Are the files bit-by-bit identical between the checkouts? I guess it might be an issue in the index.
Apr 25 2022
The build types control three different aspects, so maybe you could even present this as a table:
Apr 24 2022
Apr 22 2022
Apr 21 2022
We could also point to https://llvm.org/docs/CMake.html if no CMAKE_BUILD_TYPE is given. Depending on the use case (e.g. debug info might actually be wanted) other flags might be helpful like BUILD_SHARED_LIBS or LLVM_USE_SPLIT_DWARF. Or if you're working on frontend topics, set LLVM_TARGETS_TO_BUILD=Native. Some of these have a greater effect on build time/size than CMAKE_BUILD_TYPE=Release in my experience, and the page lists these options quite nicely.
Apr 20 2022
Mar 29 2022
Mar 28 2022
Note that __int128_t is not available everywhere, generally only on 64-bit platforms.
Mar 27 2022
Mar 24 2022
Feel free to fix that on commit.
Mar 23 2022
Just some suggestions, feel free to ignore them.
Mar 22 2022
Mar 21 2022
Mar 20 2022
Seems to have broken the documentation build:
Warning, treated as error: /home/buildbot/llvm-build-dir/llvm-sphinx-docs/llvm/src/llvm/docs/MemorySSA.rst:168:Unknown target name: "build-time use optimization".
I was also wondering if we could block the overflow intrinsics only if Subtarget.getTargetTriple().isGNUEnvironment() is true, but we can also discuss this separately. (That would affect all targets then, I guess.)
Had to adapt two more tests where we were emitting __multi3 calls on PowerPC 32-bit. That builtin doesn't exist even in compiler-rt, so I guess it's an improvement.