History log of /llvm-project/clang/lib/Sema/SemaExprMember.cpp (Results 1 – 25 of 242)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 5ede7b6a 22-Jan-2025 Krystian Stasiowski <sdkrystian@gmail.com>

Revert "Reapply "[Clang][Sema] Use the correct lookup context when building overloaded 'operator->' in the current instantiation (#104458)"" (#123982)

Reverts llvm/llvm-project#109422


# 195a1fc5 22-Jan-2025 Krystian Stasiowski <sdkrystian@gmail.com>

Reapply "[Clang][Sema] Use the correct lookup context when building overloaded 'operator->' in the current instantiation (#104458)" (#109422)

Reapplies #104458, fixing a bug that occurs when a class

Reapply "[Clang][Sema] Use the correct lookup context when building overloaded 'operator->' in the current instantiation (#104458)" (#109422)

Reapplies #104458, fixing a bug that occurs when a class member access expression calls an `operator->` operator function that returns a non-dependent class type.

show more ...


Revision tags: llvmorg-19.1.7
# cf7b3f8d 20-Dec-2024 William Tran-Viet <wtranviet@proton.me>

Fix double-quotes in diagnostic when attempting to access a ext_vector of bools (#118186)

Fixes #116932

- Remove the quotation marks in the diagnostic message for
err_ext_vector_component_name_ill

Fix double-quotes in diagnostic when attempting to access a ext_vector of bools (#118186)

Fixes #116932

- Remove the quotation marks in the diagnostic message for
err_ext_vector_component_name_illegal
- Pass in the quotation marks directly when reporting an illegal vector
component name inside `CheckExtVectorComponent`
- Add an offset to the `OpLoc` passed into `S.Diag` so the error message
arrow points directly to the offending illegal component rather than to
the '.' at the start of the component identifier.
- Modify the `vector-bool.cpp` element-wise access test case so it
(correctly) now only expects a single set of quotes.

show more ...


# db93ef14 18-Dec-2024 cor3ntin <corentinjabot@gmail.com>

[Clang] Implement CWG2813: Class member access with prvalues (#120223)

This is a rebase of #95112 with my own feedback apply as @MitalAshok has
been inactive for a while.
It's fairly important this

[Clang] Implement CWG2813: Class member access with prvalues (#120223)

This is a rebase of #95112 with my own feedback apply as @MitalAshok has
been inactive for a while.
It's fairly important this makes clang 20 as it is a blocker for #107451

---

[CWG2813](https://cplusplus.github.io/CWG/issues/2813.html)

prvalue.member_fn(expression-list) now will not materialize a temporary
for prvalue if member_fn is an explicit object member function, and
prvalue will bind directly to the object parameter.

The E1 in E1.static_member is now a discarded-value expression, so if E1
was a call to a [[nodiscard]] function, there will now be a warning.
This also affects C++98 with [[gnu::warn_unused_result]] functions.

This should not affect C where TemporaryMaterializationConversion is a
no-op.

Closes #100314
Fixes #100341

---------

Co-authored-by: Mital Ashok <mital@mitalashok.co.uk>

show more ...


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5
# 9efdebc5 26-Nov-2024 Mészáros Gergely <gergely.meszaros@intel.com>

[Clang] Only ignore special methods for unused private fields in BuildFieldReferenceExpr (#116965)

The original code assumed that only special methods might be defined as
defaulted. Since C++20 com

[Clang] Only ignore special methods for unused private fields in BuildFieldReferenceExpr (#116965)

The original code assumed that only special methods might be defined as
defaulted. Since C++20 comparison operators might be defaulted too, and
we *do* want to consider those as using the fields of the class.

Fixes: #116961

show more ...


# 7b61ff2c 21-Nov-2024 smanna12 <soumi.manna@intel.com>

[Clang] Prevent null dereferences (#115502)

This commit addresses several Static Analyzer issues related to
potential null dereference by replacing dyn_cast<> with cast<> and
getAs<> with castAs<>

[Clang] Prevent null dereferences (#115502)

This commit addresses several Static Analyzer issues related to
potential null dereference by replacing dyn_cast<> with cast<> and
getAs<> with castAs<> in various parts of the codes.

The cast function asserts that the cast is valid, ensuring that the
pointer is not null and preventing null dereference errors.

The changes are made in the following files:
CGBuiltin.cpp: Ensure vector types have exactly 3 elements.
CGExpr.cpp: Ensure member declarations are field declarations.
AnalysisBasedWarnings.cpp: Ensure operations are member expressions.
SemaExprMember.cpp: Ensure base types are extended vector types.

These changes ensure that the types are correctly cast and prevent
potential null dereference issues, improving the robustness and safety
of the code.

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.


Revision tags: 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
# 55ea3600 06-Aug-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Make UnresolvedLookupExprs in class scope explicit specializations instantiation dependent (#100392)

A class member named by an expression in a member function that may instantiate to

[Clang][Sema] Make UnresolvedLookupExprs in class scope explicit specializations instantiation dependent (#100392)

A class member named by an expression in a member function that may instantiate to a static _or_ non-static member is represented by a `UnresolvedLookupExpr` in order to defer the implicit transformation to a class member access expression until instantiation. Since `ASTContext::getDecltypeType` only creates a `DecltypeType` that has a `DependentDecltypeType` as its canonical type when the operand is instantiation dependent, and since we do not transform types unless they are instantiation dependent, we need to mark the `UnresolvedLookupExpr` as instantiation dependent in order to correctly build a `DecltypeType` using the expression as its operand with a `DependentDecltypeType` canonical type. Fixes #99873.

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 59e56eeb 15-Jul-2024 Haojian Wu <hokein.wu@gmail.com>

Revert "Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)"

This reverts commit ce4aada6e2135e29839f672a6599db628b53295d and a
follow-up patch 8ef26f1289bf069ccc0d6383f2f4c0116a120

Revert "Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)"

This reverts commit ce4aada6e2135e29839f672a6599db628b53295d and a
follow-up patch 8ef26f1289bf069ccc0d6383f2f4c0116a1206c1.

This new warning can not be fully suppressed by the
`-Wno-missing-dependent-template-keyword` flag, this gives developer no
time to do the cleanup in a large codebase, see https://github.com/llvm/llvm-project/pull/98547#issuecomment-2228250884

show more ...


# ce4aada6 11-Jul-2024 Krystian Stasiowski <sdkrystian@gmail.com>

Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)

Reapplies #92957, fixing an instance where the `template` keyword was
missing prior to a dependent name in `llvm/ADT/ArrayRef.h`

Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)

Reapplies #92957, fixing an instance where the `template` keyword was
missing prior to a dependent name in `llvm/ADT/ArrayRef.h`. An
_alias-declaration_ is used to work around a bug affecting GCC releases
before 11.1 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799) which
rejects the use of the `template` keyword prior to the
_nested-name-specifier_ in the class member access.

show more ...


# d3923354 10-Jul-2024 NAKAMURA Takumi <geek4civic@gmail.com>

Revert "[Clang] Implement resolution for CWG1835 (#92957)"

ppc64le-lld-multistage-test has been failing.

This reverts commit 7bfb98c34687d9784f36937c3ff3e735698b498a.


# 7bfb98c3 09-Jul-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang] Implement resolution for CWG1835 (#92957)

CWG1835 was one of the many core issues resolved by P1787R6: "Declarations and where to
find them" (http://wg21.link/p1787r6). Its resolution chang

[Clang] Implement resolution for CWG1835 (#92957)

CWG1835 was one of the many core issues resolved by P1787R6: "Declarations and where to
find them" (http://wg21.link/p1787r6). Its resolution changes how
member-qualified names (as defined by [basic.lookup.qual.general] p2) are looked
up. This patch implementation that resolution.

Previously, an _identifier_ following `.` or `->` would be first looked
up in the type of the object expression (i.e. qualified lookup), and
then in the context of the _postfix-expression_ (i.e. unqualified
lookup) if nothing was found; the result of the second lookup was
required to name a class template. Notably, this second lookup would
occur even when the object expression was dependent, and its result
would be used to determine whether a `<` token is the start of a
_template-argument_list_.

The new wording in [basic.lookup.qual.general] p2 states:
> A member-qualified name is the (unique) component name, if any, of
> - an _unqualified-id_ or
> - a _nested-name-specifier_ of the form _`type-name ::`_ or
_`namespace-name ::`​_
>
> in the id-expression of a class member access expression. A
***qualified name*** is
> - a member-qualified name or
> - the terminal name of
> - a _qualified-id_,
> - a _using-declarator_,
> - a _typename-specifier_,
> - a _qualified-namespace-specifier_, or
> - a _nested-name-specifier_, _elaborated-type-specifier_, or
_class-or-decltype_ that has a _nested-name-specifier_.
>
> The _lookup context_ of a member-qualified name is the type of its
associated object expression (considered dependent if the object
expression is type-dependent). The lookup context of any other qualified
name is the type, template, or namespace nominated by the preceding
_nested-name-specifier_.

And [basic.lookup.qual.general] p3 now states:
> _Qualified name lookup_ in a class, namespace, or enumeration performs
a search of the scope associated with it except as specified below.
Unless otherwise specified, a qualified name undergoes qualified name
lookup in its lookup context from the point where it appears unless the
lookup context either is dependent and is not the current instantiation
or is not a class or class template. If nothing is found by qualified
lookup for a member-qualified name that is the terminal name of a
_nested-name-specifier_ and is not dependent, it undergoes unqualified
lookup.

In non-standardese terms, these two paragraphs essentially state the
following:
- A name that immediately follows `.` or `->` in a class member access
expression is a member-qualified name
- A member-qualified name will be first looked up in the type of the
object expression `T` unless `T` is a dependent type that is _not_ the
current instantiation, e.g.
```
template<typename T>
struct A
{
void f(T* t)
{
this->x; // type of the object expression is 'A<T>'. although 'A<T>' is dependent, it is the
// current instantiation so we look up 'x' in the template definition context.

t->y; // type of the object expression is 'T' ('->' is transformed to '.' per [expr.ref]).
// 'T' is dependent and is *not* the current instantiation, so we lookup 'y' in the
// template instantiation context.
}
};
```
- If the first lookup finds nothing and:
- the member-qualified name is the first component of a
_nested-name-specifier_ (which could be an _identifier_ or a
_simple-template-id_), and either:
- the type of the object expression is the current instantiation and it
has no dependent base classes, or
- the type of the object expression is not dependent

then we lookup the name again, this time via unqualified lookup.

Although the second (unqualified) lookup is stated not to occur when the
member-qualified name is dependent, a dependent name will _not_ be
dependent once the template is instantiated, so the second lookup must
"occur" during instantiation if qualified lookup does not find anything.
This means that we must perform the second (unqualified) lookup during
parsing even when the type of the object expression is dependent, but
those results are _not_ used to determine whether a `<` token is the
start of a _template-argument_list_; they are stored so we can replicate
the second lookup during instantiation.

In even simpler terms (paraphrasing the meeting minutes from the review of P1787; see https://wiki.edg.com/bin/view/Wg21summer2020/P1787%28Lookup%29Review2020-06-15Through2020-06-18):
- Unqualified lookup always happens for the first name in a
_nested-name-specifier_ that follows `.` or `->`
- The result of that lookup is only used to determine whether `<` is the
start of a _template-argument-list_ if the first (qualified) lookup
found nothing and the lookup context:
- is not dependent, or
- is the current instantiation and has no dependent base classes.

An example:
```
struct A
{
void f();
};

template<typename T>
using B = A;

template<typename T>
struct C : A
{
template<typename U>
void g();

void h(T* t)
{
this->g<int>(); // ok, '<' is the start of a template-argument-list ('g' was found via qualified lookup in the current instantiation)
this->B<void>::f(); // ok, '<' is the start of a template-argument-list (current instantiation has no dependent bases, 'B' was found via unqualified lookup)
t->g<int>(); // error: '<' means less than (unqualified lookup does not occur for a member-qualified name that isn't the first component of a nested-name-specifier)
t->B<void>::f(); // error: '<' means less than (unqualified lookup does not occur if the name is dependent)
t->template B<void>::f(); // ok: '<' is the start of a template-argument-list ('template' keyword used)
}
};
```

Some additional notes:
- Per [basic.lookup.qual.general] p1, lookup for a
member-qualified name only considers namespaces, types, and templates
whose specializations are types if it's an _identifier_ followed by
`::`; lookup for the component name of a _simple-template-id_ followed
by `::` is _not_ subject to this rule.
- The wording which specifies when the second unqualified lookup occurs
appears to be paradoxical. We are supposed to do it only for the first
component name of a _nested-name-specifier_ that follows `.` or `->`
when qualified lookup finds nothing. However, when that name is followed
by `<` (potentially starting a _simple-template-id_) we don't _know_
whether it will be the start of a _nested-name-specifier_ until we do
the lookup -- but we aren't supposed to do the lookup until we know it's
part of a _nested-name-specifier_! ***However***, since we only do the
second lookup when the first lookup finds nothing (and the name isn't
dependent), ***and*** since neither lookup is type-only, the only valid
option is for the name to be the _template-name_ in a
_simple-template-id_ that is followed by `::` (it can't be an
_unqualified-id_ naming a member because we already determined that the
lookup context doesn't have a member with that name). Thus, we can lock
into the _nested-name-specifier_ interpretation and do the second lookup
without having to know whether the _simple-template-id_ will be followed
by `::` yet.

show more ...


# 9e1f1cfa 09-Jul-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (#98167)

The following code causes an assert in `SemaExprMember.cpp` on line 9

[Clang][Sema] Handle class member access expressions with valid nested-name-specifiers that become invalid after lookup (#98167)

The following code causes an assert in `SemaExprMember.cpp` on line 981
to fail:
```
struct A { };
struct B;

void f(A *x) {
x->B::y; // crash here
}
```
This happens because we only return early from
`BuildMemberReferenceExpr` when the `CXXScopeSpecifier` is invalid
_before_ the lookup is performed. Since the lookup may invalidate the
`CXXScopeSpecifier` (e.g. if the _nested-name-specifier_ is incomplete),
this results in the second `BuildMemberReferenceExpr` overload being
called with an invalid `CXXScopeSpecifier`, which causes the assert to
fail. This patch moves the early return for invalid `CXXScopeSpecifiers`
to occur _after_ lookup is performed. This fixes #92972.

I also removed the `if (SS.isSet() && SS.isInvalid())` check in
`ActOnMemberAccessExpr` because the condition can never be true (`isSet`
returns `getScopeRep() != nullptr` and `isInvalid` returns
`Range.isValid() && getScopeRep() == nullptr`).

show more ...


# bae2c549 01-Jul-2024 Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>

[clang][NFC] Move documentation of `Sema` functions into `Sema.h`

This patch moves documentation of `Sema` functions from `.cpp` files to `Sema.h` when there was no documentation in the latter, or i

[clang][NFC] Move documentation of `Sema` functions into `Sema.h`

This patch moves documentation of `Sema` functions from `.cpp` files to `Sema.h` when there was no documentation in the latter, or it can be trivially subsumed. More complicated cases when there's less trivial divergence between documentation attached to declaration and the one attached to implementation are left for a later PR that would require review.

It appears that doxygen can find the documentation for a function defined out-of-line even if it's attached to an implementation, and not declaration. But other tools, e.g. clangd, are not as powerful. So this patch significantly improves autocompletion experience for (at least) clangd-based IDEs.

show more ...


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7
# 9c4a716c 29-May-2024 Matheus Izvekov <mizvekov@gmail.com>

[clang] Preserve Qualifiers and type sugar in TemplateNames (#93433)

This patch improves the preservation of qualifiers and loss of type
sugar in TemplateNames.

This problem is analogous to https:/

[clang] Preserve Qualifiers and type sugar in TemplateNames (#93433)

This patch improves the preservation of qualifiers and loss of type
sugar in TemplateNames.

This problem is analogous to https://reviews.llvm.org/D112374 and this
patch takes a very similar approach to that patch, except the impact
here is much lesser.

When a TemplateName was written bare, without qualifications, we
wouldn't produce a QualifiedTemplate which could be used to disambiguate
it from a Canonical TemplateName. This had effects in the TemplateName
printer, which had workarounds to deal with this, and wouldn't print the
TemplateName as-written in most situations.

There are also some related fixes to help preserve this type sugar along
the way into diagnostics, so that this patch can be properly tested.

- Fix dropping the template keyword.
- Fix type deduction to preserve sugar in TST TemplateNames.

show more ...


Revision tags: llvmorg-18.1.6
# 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 ...


# 596a9c1f 13-May-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Fix bug where operator-> typo corrects in the current instantiation (#91972)

#90152 introduced a bug that occurs when typo-correction attempts to fix a reference to a
non-existent mem

[Clang][Sema] Fix bug where operator-> typo corrects in the current instantiation (#91972)

#90152 introduced a bug that occurs when typo-correction attempts to fix a reference to a
non-existent member of the current instantiation (even though
`operator->` may return a different type than the object type). This
patch fixes it by simply considering the object expression to be of type
`ASTContext::DependentTy` when the arrow operator is used with a
dependent non-pointer non-function operand (after any implicit
conversions).

show more ...


# 75ebcbf2 09-May-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Revert changes to operator= lookup in templated classes from #91498, #90999, and #90152 (#91620)

This reverts changes in #91498, #90999, and #90152 which make
`operator=` dependent wh

[Clang][Sema] Revert changes to operator= lookup in templated classes from #91498, #90999, and #90152 (#91620)

This reverts changes in #91498, #90999, and #90152 which make
`operator=` dependent whenever the current class is templated.

show more ...


Revision tags: llvmorg-18.1.5
# 8009bbec 30-Apr-2024 Krystian Stasiowski <sdkrystian@gmail.com>

Reapply "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)" (#90

Reapply "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)" (#90152)

Reapplies #84050, addressing a bug which cases a crash when an
expression with the type of the current instantiation is used as the
_postfix-expression_ in a class member access expression (arrow form).

show more ...


# 0c6e1ca1 26-Apr-2024 Pranav Kant <prka@google.com>

Revert "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)"

This

Revert "[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)"

This reverts commit a8fd0d029dca7d17eee72d0445223c2fe1ee7758.

show more ...


# 45fc0e6b 26-Apr-2024 Pranav Kant <prka@google.com>

Revert "[Clang][Sema] Fix warnings after #84050 (#90104)"

This reverts commit 6dd2617c80d5133b92fdff679364f2d8fcd93b47.


# 6dd2617c 25-Apr-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Fix warnings after #84050 (#90104)


# a8fd0d02 25-Apr-2024 Krystian Stasiowski <sdkrystian@gmail.com>

[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)

Consider the

[Clang][Sema] Diagnose class member access expressions naming non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)

Consider the following:
```cpp
template<typename T>
struct A
{
auto f()
{
return this->x;
}
};
```
Although `A` has no dependent base classes and the lookup context for
`x` is the current instantiation, we currently do not diagnose the
absence of a member `x` until `A<T>::f` is instantiated. This patch
moves the point of diagnosis for such expressions to occur at the point
of definition (i.e. prior to instantiation).

show more ...


# 5c4b923c 22-Apr-2024 Krystian Stasiowski <sdkrystian@gmail.com>

Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent class scope function template specialization that instantiates to a static member function (#87541, #88311)" (#88731)

Reapplies #8

Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent class scope function template specialization that instantiates to a static member function (#87541, #88311)" (#88731)

Reapplies #87541 and #88311 (again) addressing the bug which caused
expressions naming overload sets to be incorrectly rebuilt, as well as
the bug which caused base class members to always be treated as overload
sets.

The primary change since #88311 is `UnresolvedLookupExpr::Create` is called directly in `BuildPossibleImplicitMemberExpr` with `KnownDependent` as `true` (which causes the expression type to be set to `ASTContext::DependentTy`). This ensures that any further semantic analysis involving the type of the potentially implicit class member access expression is deferred until instantiation.

show more ...


# 458328ae 17-Apr-2024 Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>

[clang][NFC] Refactor `Sema::RedeclarationKind`

This patch converts the enum into scoped enum, and moves it into its own header for the time being. It's definition is needed in `Sema.h`, and is goin

[clang][NFC] Refactor `Sema::RedeclarationKind`

This patch converts the enum into scoped enum, and moves it into its own header for the time being. It's definition is needed in `Sema.h`, and is going to be needed in upcoming `SemaObjC.h`. `Lookup.h` can't hold it, because it includes `Sema.h`.

show more ...


12345678910