#
7ab8f286 |
| 29-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#124883)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#124883)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
This patch migrates the use of PointerUnion::dyn_cast to dyn_cast_if_present because ShadowMapEntry::Add starts with:
if (DeclOrVector.isNull()) {
implying that DeclOrVector is not guaranteed to be nonnull.
show more ...
|
Revision tags: llvmorg-21-init |
|
#
62bd217b |
| 25-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#124391)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#124391)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
Literal migration would result in dyn_cast_if_present (see the definition of PointerUnion::dyn_cast), but this patch uses dyn_cast because we expect DeclOrIterator to be nonnull.
show more ...
|
#
ba174855 |
| 23-Jan-2025 |
Nathan Ridge <zeratul976@hotmail.com> |
[clang][CodeComplete] Use HeuristicResolver to resolve DependentNameTypes (#123818)
Fixes https://github.com/clangd/clangd/issues/1249
|
#
1d23fb97 |
| 22-Jan-2025 |
Nathan Ridge <zeratul976@hotmail.com> |
[clang][CodeComplete] Use HeuristicResolver to resolve pointee types (#121315)
Fixes https://github.com/clangd/clangd/issues/810
|
#
e673f9d0 |
| 14-Jan-2025 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#122855)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast
[Sema] Migrate away from PointerUnion::dyn_cast (NFC) (#122855)
Note that PointerUnion::dyn_cast has been soft deprecated in PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with // isa<T>, cast<T> and the llvm::dyn_cast<T>
Literal migration would result in dyn_cast_if_present (see the definition of PointerUnion::dyn_cast), but this patch uses dyn_cast because we expect DeclOrVector to be nonnull.
show more ...
|
Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
1e3e199e |
| 27-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Sema] Migrate away from PointerUnion::{is,get} (NFC) (#117498)
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_
[Sema] Migrate away from PointerUnion::{is,get} (NFC) (#117498)
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
I'm not touching PointerUnion::dyn_cast for now because it's a bit
complicated; we could blindly migrate it to dyn_cast_if_present, but
we should probably use dyn_cast when the operand is known to be
non-null.
show more ...
|
#
ec4c47d9 |
| 26-Nov-2024 |
ykiko <ykikoykikoykiko@gmail.com> |
Add code completion for C++20 keywords. (#107982)
This commit adds code completion for C++20 keywords, fix
https://github.com/llvm/llvm-project/issues/107868.
1. complete `concept` in template c
Add code completion for C++20 keywords. (#107982)
This commit adds code completion for C++20 keywords, fix
https://github.com/llvm/llvm-project/issues/107868.
1. complete `concept` in template context
- [x] `template<typename T> conce^` -> `concept`
- [ ] `conce^`
2. complete `requires`
- [x] constraints in template context: `template<typename T> requi^` ->
`requires`
- [x] requires expression: `int x = requ^` -> `requires (parameters) {
requirements }`
- [x] nested requirement: `requires { requ^ }` -> `requires expression
;`
3. complete coroutine keywords
- [x] `co_await^` in expression: `co_aw^` -> `co_await expression;`
- [x] `co_yield` in function body: `co_yi^` -> `co_yield expression;`
- [x] `co_return` in function body: `co_re^` -> `co_return expression;`
4. specifiers: `char8_t`, `consteval`, `constinit`
show more ...
|
Revision tags: llvmorg-19.1.4 |
|
#
46d750be |
| 16-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Sema] Remove unused includes (NFC) (#116461)
Identified with misc-include-cleaner.
|
#
b9d678d2 |
| 15-Nov-2024 |
Joseph Huber <huberjn@outlook.com> |
[Clang] Use TargetInfo when deciding if an address space is compatible (#115777)
Summary: Address spaces are used in several embedded and GPU targets to describe accesses to different types of memo
[Clang] Use TargetInfo when deciding if an address space is compatible (#115777)
Summary: Address spaces are used in several embedded and GPU targets to describe accesses to different types of memory. Currently we use the address space enumerations to control which address spaces are considered supersets of eachother, however this is also a target level property as described by the C standard's passing mentions. This patch allows the address space checks to use the target information to decide if a pointer conversion is legal. For AMDGPU and NVPTX, all supported address spaces can be converted to the default address space.
More semantic checks can be added on top of this, for now I'm mainly looking to get more standard semantics working for C/C++. Right now the address space conversions must all be done explicitly in C/C++ unlike the offloading languages which define their own custom address spaces that just map to the same target specific ones anyway. The main question is if this behavior is a function of the target or the language.
show more ...
|
#
dde802b1 |
| 15-Nov-2024 |
Sirraide <aeternalmail@gmail.com> |
[Clang] [NFC] Refactor AST visitors in Sema and the static analyser to use DynamicRecursiveASTVisitor (#115144)
This pr refactors all recursive AST visitors in `Sema`, `Analyze`, and
`StaticAnalysi
[Clang] [NFC] Refactor AST visitors in Sema and the static analyser to use DynamicRecursiveASTVisitor (#115144)
This pr refactors all recursive AST visitors in `Sema`, `Analyze`, and
`StaticAnalysis` to inherit from DRAV instead. This is over half of the
visitors that inherit from RAV directly.
See also #115132, #110040, #93462
LLVM Compile-Time Tracker link for this branch:
https://llvm-compile-time-tracker.com/compare.php?from=5adb5c05a2e9f31385fbba8b0436cbc07d91a44d&to=b58e589a86c06ba28d4d90613864d10be29aa5ba&stat=instructions%3Au
show more ...
|
Revision tags: llvmorg-19.1.3 |
|
#
4dd55c56 |
| 24-Oct-2024 |
Jay Foad <jay.foad@amd.com> |
[clang] Use {} instead of std::nullopt to initialize empty ArrayRef (#109399)
Follow up to #109133.
|
Revision tags: llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
1881f648 |
| 16-Sep-2024 |
Aaron Ballman <aaron@aaronballman.com> |
Remove ^^ as a token in OpenCL (#108224)
OpenCL has a reserved operator (^^), the use of which was diagnosed as
an error (735c6cdebdcd4292928079cb18a90f0dd5cd65fb). However, OpenCL
also encourages
Remove ^^ as a token in OpenCL (#108224)
OpenCL has a reserved operator (^^), the use of which was diagnosed as
an error (735c6cdebdcd4292928079cb18a90f0dd5cd65fb). However, OpenCL
also encourages working with the blocks language extension. This token
has a parsing ambiguity as a result. Consider:
unsigned x=0;
unsigned y=x^^{return 0;}();
This should result in y holding the value zero (0^0) through an
immediately invoked block call as the right-hand side of the xor
operator. However, it causes errors instead because of this reserved
token: https://godbolt.org/z/navf7jTv1
This token is still reserved in OpenCL 3.0, so we still wish to issue a
diagnostic for its use. However, we do not need to create a token for an
extension point that's been unused for about a decade. So this patch
moves the diagnostic from a parsing diagnostic to a lexing diagnostic
and no longer forms a single token. The diagnostic behavior is slightly
worse as a result, but still seems acceptable.
Part of the reason this is coming up is because WG21 is considering
using ^^ as a token for reflection, so this token may come back in the
future.
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
e6ec7c8f |
| 15-Jul-2024 |
Krystian Stasiowski <sdkrystian@gmail.com> |
[Clang][AST] Move NamespaceDecl bits to DeclContext (#98567)
Currently, `NamespaceDecl` has a member `AnonOrFirstNamespaceAndFlags`
which stores a few pieces of data:
- a bit indicating whether th
[Clang][AST] Move NamespaceDecl bits to DeclContext (#98567)
Currently, `NamespaceDecl` has a member `AnonOrFirstNamespaceAndFlags`
which stores a few pieces of data:
- a bit indicating whether the namespace was declared `inline`, and
- a bit indicating whether the namespace was declared as a
_nested-namespace-definition_, and
- a pointer a `NamespaceDecl` that either stores:
- a pointer to the first declaration of that namespace if the
declaration is no the first declaration, or
- a pointer to the unnamed namespace that inhabits the namespace
otherwise.
`Redeclarable` already stores a pointer to the first declaration of an
entity, so it's unnecessary to store this in `NamespaceDecl`.
`DeclContext` has 8 bytes in which various bitfields can be stored for a
declaration, so it's not necessary to store these in `NamespaceDecl`
either. We only need to store a pointer to the unnamed namespace that
inhabits the first declaration of a namespace. This patch moves the two
bits currently stored in `NamespaceDecl` to `DeclContext`, and only
stores a pointer to the unnamed namespace that inhabits a namespace in
the first declaration of that namespace. Since `getOriginalNamespace`
always returns the same `NamespaceDecl` as `getFirstDecl`, this function
is removed to avoid confusion.
show more ...
|
#
c22625cb |
| 08-Jul-2024 |
Aaron Ballman <aaron@aaronballman.com> |
[C2y] Remove support for _Imaginary (#97436)
WG14 N3274 removed _Imaginary from Annex G. Clang has never fully
supported Annex G or _Imaginary, so removal is pretty trivial for us.
Note, we are
[C2y] Remove support for _Imaginary (#97436)
WG14 N3274 removed _Imaginary from Annex G. Clang has never fully
supported Annex G or _Imaginary, so removal is pretty trivial for us.
Note, we are keeping _Imaginary as a keyword so that we get better
diagnostic behavior. This is still conforming because _I makes it a
reserved identifier, so it's not available for users to use as an
identifier anyway.
show more ...
|
#
ccc0b66d |
| 05-Jul-2024 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[clang] Avoid 'raw_string_ostream::str' (NFC)
Since `raw_string_ostream` doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer
[clang] Avoid 'raw_string_ostream::str' (NFC)
Since `raw_string_ostream` doesn't own the string buffer, it is desirable (in terms of memory safety) for users to directly reference the string buffer rather than use `raw_string_ostream::str()`.
Work towards TODO item to remove `raw_string_ostream::str()`.
p.s. also remove some unneeded/dead code.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
7429950d |
| 27-May-2024 |
Younan Zhang <zyn7109@gmail.com> |
[clang][CodeComplete] Recurse into the subexpression of deref operator in getApproximateType (#93404)
The issue with the previous implementation bc31be7 was that
getApproximateType could potentiall
[clang][CodeComplete] Recurse into the subexpression of deref operator in getApproximateType (#93404)
The issue with the previous implementation bc31be7 was that
getApproximateType could potentially return a null QualType for a
dereferencing operator, which is not what its caller wants.
show more ...
|
Revision tags: llvmorg-18.1.6 |
|
#
874f511a |
| 17-May-2024 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang] Introduce `SemaCodeCompletion` (#92311)
This patch continues previous efforts to split `Sema` up, this time
covering code completion.
Context can be found in #84184.
Dropping `Code` prefi
[clang] Introduce `SemaCodeCompletion` (#92311)
This patch continues previous efforts to split `Sema` up, this time
covering code completion.
Context can be found in #84184.
Dropping `Code` prefix from function names in `SemaCodeCompletion` would
make sense, but I think this PR has enough changes already.
As usual, formatting changes are done as a separate commit. Hopefully
this helps with the review.
show more ...
|
#
31a203fa |
| 13-May-2024 |
Vlad Serebrennikov <serebrennikov.vladislav@gmail.com> |
[clang] Introduce `SemaObjC` (#89086)
This is continuation of efforts to split `Sema` up, following the
example of OpenMP, OpenACC, etc. Context can be found in
https://github.com/llvm/llvm-projec
[clang] Introduce `SemaObjC` (#89086)
This is continuation of efforts to split `Sema` up, following the
example of OpenMP, OpenACC, etc. Context can be found in
https://github.com/llvm/llvm-project/pull/82217 and
https://github.com/llvm/llvm-project/pull/84184.
I split formatting changes into a separate commit to help reviewing the
actual changes.
show more ...
|
#
deffae5d |
| 11-May-2024 |
Kazu Hirata <kazu@google.com> |
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber Str
[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
24 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
show more ...
|
#
a2f97974 |
| 02-May-2024 |
smanna12 <soumi.manna@intel.com> |
[Clang] Prevent null pointer dereference in Sema::CodeCompleteQualifiedId() (#90490)
The null pointer dereference issue seems happening with in the
expression NNS->getAsType().
Although dyn_cas
[Clang] Prevent null pointer dereference in Sema::CodeCompleteQualifiedId() (#90490)
The null pointer dereference issue seems happening with in the
expression NNS->getAsType().
Although dyn_cast_or_null<TemplateTypeParmType>() correctly handles null
pointers, it doesn’t prevent the subsequent dereferencing operation.
The fix ensures that NNS pointer is not null before calling the
getAsType() method, thus preventing potential runtime errors caused by
attempting to access a null pointer.
show more ...
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4 |
|
#
fca51911 |
| 11-Apr-2024 |
Bill Wendling <5993918+bwendling@users.noreply.github.com> |
[NFC][Clang] Improve const correctness for IdentifierInfo (#79365)
The IdentifierInfo isn't typically modified. Use 'const' wherever
possible.
|
Revision tags: llvmorg-18.1.3 |
|
#
bc31be79 |
| 26-Mar-2024 |
Nathan Ridge <zeratul976@hotmail.com> |
[clang][CodeComplete] Handle deref operator in getApproximateType (#86466)
This allows completing after `(*this).` in a dependent context.
Fixes https://github.com/clangd/clangd/issues/1952
|
Revision tags: llvmorg-18.1.2 |
|
#
beb47e78 |
| 12-Mar-2024 |
Michael Buch <michaelbuch12@gmail.com> |
[clang][CodeCompletion] Allow debuggers to code-complete reserved identifiers (#84891)
|
Revision tags: llvmorg-18.1.1 |
|
#
7bad74e6 |
| 06-Mar-2024 |
Qwinci <32550582+Qwinci@users.noreply.github.com> |
[clangd] Show argument names for function pointer struct fields (#69011)
Show argument names in signature help when calling a function pointer
struct field.
|
Revision tags: 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 |
|
#
f3dcc235 |
| 13-Dec-2023 |
Kazu Hirata <kazu@google.com> |
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}:
[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
show more ...
|