History log of /llvm-project/clang/lib/Sema/SemaCodeComplete.cpp (Results 1 – 25 of 748)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...30