Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
273777ea |
| 28-May-2024 |
Aaron Ballman <aaron@aaronballman.com> |
clang:: to llvm::; NFC
These interfaces are LLVM interfaces, not Clang ones; but this worked because of LLVM.h adding the interfaces to the clang namespace.
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init |
|
#
6ad0788c |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is p
[clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h".
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
a1580d7b |
| 14-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Option
[clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.7 |
|
#
35b4fbb5 |
| 04-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasval
[clang] Use std::nullopt instead of None in comments (NFC)
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
34e0d057 |
| 03-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[Analysis] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount o
[Analysis] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
1def2579 |
| 08-Jul-2021 |
David Blaikie <dblaikie@gmail.com> |
PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the codebase forward-compatible wit
PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the codebase forward-compatible with C++23 (& a follow-up change I've made will make this ambiguous/invalid even in <C++23 so we don't regress this & it generally improves the code anyway)
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
#
7c83799f |
| 23-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[MacroExpansionContext] Fix a warning.
This patch fixes:
error: private field 'PP' is not used [-Werror,-Wunused-private-field]
|
#
6e307100 |
| 22-Feb-2021 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Introduce MacroExpansionContext to libAnalysis
Introduce `MacroExpansionContext` to track what and how macros in a translation unit expand. This is the first element of the patch-stack in
[analyzer] Introduce MacroExpansionContext to libAnalysis
Introduce `MacroExpansionContext` to track what and how macros in a translation unit expand. This is the first element of the patch-stack in this direction.
The main goal is to substitute the current macro expansion generator in the `PlistsDiagnostics`, but all the other `DiagnosticsConsumer` could benefit from this.
`getExpandedText` and `getOriginalText` are the primary functions of this class. The former can provide you the text that was the result of the macro expansion chain starting from a `SourceLocation`. While the latter will tell you **what text** was in the original source code replaced by the macro expansion chain from that location.
Here is an example:
void bar(); #define retArg(x) x #define retArgUnclosed retArg(bar() #define BB CC #define applyInt BB(int) #define CC(x) retArgUnclosed
void unbalancedMacros() { applyInt ); //^~~~~~~~~~^ is the substituted range // Original text is "applyInt )" // Expanded text is "bar()" }
#define expandArgUnclosedCommaExpr(x) (x, bar(), 1 #define f expandArgUnclosedCommaExpr
void unbalancedMacros2() { int x = f(f(1)) )); // Look at the parenthesis! // ^~~~~~^ is the substituted range // Original text is "f(f(1))" // Expanded text is "((1,bar(),1,bar(),1" }
Might worth investigating how to provide a reusable component, which could be used for example by a standalone tool eg. expanding all macros to their definitions.
I borrowed the main idea from the `PrintPreprocessedOutput.cpp` Frontend component, providing a `PPCallbacks` instance hooking the preprocessor events. I'm using that for calculating the source range where tokens will be expanded to. I'm also using the `Preprocessor`'s `OnToken` callback, via the `Preprocessor::setTokenWatcher` to reconstruct the expanded text.
Unfortunately, I concatenate the token's string representation without any whitespaces except if the token is an identifier when I emit an extra space to produce valid code for `int var` token sequences. This could be improved later if needed.
Patch-stack: 1) D93222 (this one) Introduces the MacroExpansionContext class and unittests
2) D93223 Create MacroExpansionContext member in AnalysisConsumer and pass down to the diagnostics consumers
3) D93224 Use the MacroExpansionContext for macro expansions in plists It replaces the 'old' macro expansion mechanism.
4) D94673 API for CTU macro expansions You should be able to get a `MacroExpansionContext` for each imported TU. Right now it will just return `llvm::None` as this is not implemented yet.
5) FIXME: Implement macro expansion tracking for imported TUs as well.
It would also relieve us from bugs like: - [fixed] D86135 - [confirmed] The `__VA_ARGS__` and other macro nitty-gritty, such as how to stringify macro parameters, where to put or swallow commas, etc. are not handled correctly. - [confirmed] Unbalanced parenthesis are not well handled - resulting in incorrect expansions or even crashes. - [confirmed][crashing] https://bugs.llvm.org/show_bug.cgi?id=48358
Reviewed By: martong, Szelethus
Differential Revision: https://reviews.llvm.org/D93222
show more ...
|