|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, 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, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, 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 |
|
| #
3ff86f96 |
| 22-Jul-2022 |
Erich Keane <[email protected]> |
[NFC] Start saving InstantiatedFromDecl in non-template functions
In cases where a non-template function is defined inside a function template, we don't have information about the original uninstant
[NFC] Start saving InstantiatedFromDecl in non-template functions
In cases where a non-template function is defined inside a function template, we don't have information about the original uninstantiated version. In the case of concepts instantiation, we will need the ability to get back to the original template. This patch splits a piece of the deferred concepts instantaition patch off to accomplish the storage of this, with minor runtime overhead, and zero additional storage.
show more ...
|
| #
258c3aee |
| 01-Jul-2022 |
Erich Keane <[email protected]> |
Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.
Apparently this breaks some libc++ builds with an apparent assertion
Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.
Apparently this breaks some libc++ builds with an apparent assertion, so I'm looking into that .
show more ...
|
| #
befa8cf0 |
| 30-Jun-2022 |
Erich Keane <[email protected]> |
Re-apply "Deferred Concept Instantiation Implementation""
This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.
This fixes the lldb crash that was observed by ensuring that our friend-'temp
Re-apply "Deferred Concept Instantiation Implementation""
This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.
This fixes the lldb crash that was observed by ensuring that our friend-'template contains reference to' TreeTransform properly handles a TemplateDecl.
show more ...
|
| #
d4d47e57 |
| 30-Jun-2022 |
Jonas Devlieghere <[email protected]> |
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 because it triggers an assertion when building an LLDB test program:
Assertion
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 because it triggers an assertion when building an LLDB test program:
Assertion failed: (InstantiatingSpecializations.empty() && "failed to clean up an InstantiatingTemplate?"), function ~Sema, file /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Sema/Sema.cpp, line 458.
More details in https://reviews.llvm.org/D126907.
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
2f207439 |
| 19-May-2022 |
Erich Keane <[email protected]> |
Deferred Concept Instantiation Implementation
This is a continuation of D119544. Based on @rsmith 's feed back showing me https://eel.is/c++draft/temp#friend-9, We should properly handle friend fun
Deferred Concept Instantiation Implementation
This is a continuation of D119544. Based on @rsmith 's feed back showing me https://eel.is/c++draft/temp#friend-9, We should properly handle friend functions now.
Differential Revision: https://reviews.llvm.org/D126907
show more ...
|
| #
f13019f8 |
| 12-Jun-2022 |
Kazu Hirata <[email protected]> |
[clang] Use any_of and none_of (NFC)
|
| #
017abbb2 |
| 09-May-2022 |
Erich Keane <[email protected]> |
Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""
This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.
There is another libc++ test, that this time causes us
Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""
This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.
There is another libc++ test, that this time causes us to hit an assertion. Reverting, likely for a while this time.
show more ...
|
| #
a425cac3 |
| 05-May-2022 |
Erich Keane <[email protected]> |
"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""
This includes a fix for the libc++ issue I ran across with friend declarations not properly being identified as overloads.
Th
"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""
This includes a fix for the libc++ issue I ran across with friend declarations not properly being identified as overloads.
This reverts commit 45c07db31cc76802a1a2e41bed1ce9c1b8198181.
show more ...
|
| #
cc344d26 |
| 05-May-2022 |
Adrian Kuegel <[email protected]> |
[clang] Add static_cast to fix Bazel build.
Differential Revision: https://reviews.llvm.org/D124995
|
| #
cb5bb285 |
| 04-May-2022 |
Zixu Wang <[email protected]> |
Revert "Revert "[clang][extract-api] Use relative includes""
Reapply the change after fixing sanitizer errors. The original problem was that `StringRef`s in `Matches` are pointing to temporary local
Revert "Revert "[clang][extract-api] Use relative includes""
Reapply the change after fixing sanitizer errors. The original problem was that `StringRef`s in `Matches` are pointing to temporary local `std::string`s created by `path::convert_to_slash` in the regex match call. This patch does the conversion up front in container `FilePath`.
This reverts commit 2966f0fa505266735dbc8324b8821b7f0aa901ff.
Differential Revision: https://reviews.llvm.org/D124964
show more ...
|
| #
2966f0fa |
| 04-May-2022 |
Zixu Wang <[email protected]> |
Revert "[clang][extract-api] Use relative includes"
This reverts commit 4c262fee08b5383c96857d77eefe80d61c41d2b0. Revert to fix Msan and Asan errors.
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
4c262fee |
| 15-Apr-2022 |
Zixu Wang <[email protected]> |
[clang][extract-api] Use relative includes
This patch transforms the given input headers to relative include names using header search entries and some heuritics. For example: `/Path/To/Header.h` wi
[clang][extract-api] Use relative includes
This patch transforms the given input headers to relative include names using header search entries and some heuritics. For example: `/Path/To/Header.h` will be included as `<Header.h>` with a search path of `-I /Path/To/`; and `/Path/To/Framework.framework/Headers/Header.h` will be included as `<Framework/Header.h>`, given a search path of `-F /Path/To`. Headermaps will also be queried in reverse to find a spelled name to include headers.
Differential Revision: https://reviews.llvm.org/D123831
show more ...
|
| #
45c07db3 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""
This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.
The patch caused some problems with the libc++ `__range_a
Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""
This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.
The patch caused some problems with the libc++ `__range_adaptor_closure` that I haven't been able to figure out the cause of, so I am reverting while I figure out whether this is a solvable problem/issue with the CFE, or libc++ depending on an older 'incorrect' behavior.
show more ...
|
| #
a9789910 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""
This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.
I've solved the issue with the PointerUnion by making the `Functio
Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""
This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.
I've solved the issue with the PointerUnion by making the `FunctionTemplateDecl` pointer be a NamedDecl, that could be a `FunctionDecl` or `FunctionTemplateDecl` depending. This is enforced with an assert.
show more ...
|
| #
0c31da48 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.
The patch caused numerous ARM 32 bit build failures, since we added a 5th item t
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.
The patch caused numerous ARM 32 bit build failures, since we added a 5th item to the PointerUnion, and went over the 2-bits available in the 32 bit pointers.
show more ...
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
4b6c2cd6 |
| 03-Mar-2022 |
Erich Keane <[email protected]> |
Deferred Concept Instantiation Implementation
As reported here: https://github.com/llvm/llvm-project/issues/44178
Concepts are not supposed to be instantiated until they are checked, so this patch
Deferred Concept Instantiation Implementation
As reported here: https://github.com/llvm/llvm-project/issues/44178
Concepts are not supposed to be instantiated until they are checked, so this patch implements that and goes through significant amounts of work to make sure we properly re-instantiate the concepts correctly.
Differential Revision: https://reviews.llvm.org/D119544
show more ...
|
| #
2d133867 |
| 28-Apr-2022 |
Duncan P. N. Exon Smith <[email protected]> |
Frontend: Delete output streams before closing CompilerInstance outputs
Delete the output streams coming from CompilerInstance::createOutputFile() and friends once writes are finished. Concretely, r
Frontend: Delete output streams before closing CompilerInstance outputs
Delete the output streams coming from CompilerInstance::createOutputFile() and friends once writes are finished. Concretely, replacing `OS->flush()` with `OS.reset()` in:
- `ExtractAPIAction::EndSourceFileAction()` - `PrecompiledPreambleAction::setEmittedPreamblePCH()` - `cc1_main()'s support for `-ftime-trace`
This fixes theoretical bugs related to proxy streams, which may have cleanups to run in their destructor. For example, a proxy that CompilerInstance sometimes uses is `buffer_ostream`, which wraps a `raw_ostream` lacking pwrite support and adds it. `flush()` does not promise that output is complete; `buffer_ostream` needs to wait until the destructor to forward anything so that it can service later calls to `pwrite()`. If the destructor isn't called then the proxied stream hasn't received any content.
This also protects against some logic bugs, triggering a null dereference on a later attempt to write to the stream.
No tests, since in practice these particular code paths never use use `buffer_ostream`; you need to be writing a binary file to a pipe (such as stdout) to hit it, but `-extract-api` writes a text file and the other two use computed filenames that will never (in practice) be a pipe. This is effectively NFC, for now.
But I have some other patches in the works that add guard rails, crashing if the stream hasn't been destructed by the time the CompilerInstance is told to keep the output file, since in most cases this is a problem.
Differential Revision: https://reviews.llvm.org/D124635
show more ...
|
| #
7443a504 |
| 11-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api] Add support for true anonymous enums
Anonymous enums without a typedef should have a "(anonymous)" identifier.
Differential Revision: https://reviews.llvm.org/D123533
|
| #
236b6a0e |
| 07-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.
- Split GlobalRecord into two distinct types to be able to introduce has_function_signature type trait. - Add has_function_sign
[clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.
- Split GlobalRecord into two distinct types to be able to introduce has_function_signature type trait. - Add has_function_signature type trait. - Serialize function signatures as part of serializeAPIRecord for records that are known to have a function signature.
Differential Revision: https://reviews.llvm.org/D123304
show more ...
|
| #
10155922 |
| 07-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api][NFC] Use dedicated API to check for macro equality
Differential Revision: https://reviews.llvm.org/D123295
|
| #
aebe5fc6 |
| 05-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api] Process only APIs declared in inputs
We should only process APIs declared in the command line inputs to avoid drowning the ExtractAPI output with symbols the user doesn't care a
[clang][extract-api] Process only APIs declared in inputs
We should only process APIs declared in the command line inputs to avoid drowning the ExtractAPI output with symbols the user doesn't care about. This is achieved by keeping track of the provided input files and checking that the associated Decl or Macro is declared in one of those files.
Differential Revision: https://reviews.llvm.org/D123148
show more ...
|
| #
178aad9b |
| 31-Mar-2022 |
Zixu Wang <[email protected]> |
[clang][extract-api] Add Objective-C Category support
Add (partial) support for Objective-C category records in ExtractAPI. The current ExtractAPI collects everything for an Objective-C category, bu
[clang][extract-api] Add Objective-C Category support
Add (partial) support for Objective-C category records in ExtractAPI. The current ExtractAPI collects everything for an Objective-C category, but not fully serialized in the SymbolGraphSerializer. Categories extending external interfaces are disgarded during serialization, and categories extending known interfaces are merged (all members surfaced) into the interfaces.
Differential Revision: https://reviews.llvm.org/D122774
show more ...
|
| #
9fc45ca0 |
| 01-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api] Add support for typedefs
Typedef records consist of the symbol associated with the underlying TypedefDecl and a SymbolReference to the underlying type. Additionally typedefs for
[clang][extract-api] Add support for typedefs
Typedef records consist of the symbol associated with the underlying TypedefDecl and a SymbolReference to the underlying type. Additionally typedefs for anonymous TagTypes use the typedef'd name as the symbol name in their respective records and USRs. As a result the declaration fragments for the anonymous TagType are those for the associated typedef. This means that when the user is defining a typedef to a typedef to a anonymous type, we use a reference the anonymous TagType itself and do not emit the typedef to the anonymous type in the generated symbol graph, including in the type destination of further typedef symbol records.
Differential Revision: https://reviews.llvm.org/D123019
show more ...
|
| #
8b63622b |
| 04-Apr-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api] Undefining macros should not result in a crash
This fixes the situation where a undefining a not previously defined macro resulted in a crash. Before trying to remove a definiti
[clang][extract-api] Undefining macros should not result in a crash
This fixes the situation where a undefining a not previously defined macro resulted in a crash. Before trying to remove a definition from PendingMacros we first check to see if the macro did indeed have a previous definition.
Differential Revision: https://reviews.llvm.org/D123056
show more ...
|
| #
985eaa1a |
| 30-Mar-2022 |
Daniel Grumberg <[email protected]> |
[clang][extract-api][NFC] Don't remap the generated input buffer in PPOpts
This was triggering some build failures so removing this change for now.
|