aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaExprMember.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-06-13Remove delayed typo expressions (#143423)Aaron Ballman1-112/+4
This removes the delayed typo correction functionality from Clang (regular typo correction still remains) due to fragility of the solution. An RFC was posted here: https://discourse.llvm.org/t/rfc-removing-support-for-delayed-typo-correction/86631 and while that RFC was asking for folks to consider stepping up to be maintainers, and we did have a few new contributors show some interest, experiments show that it's likely worth it to remove this functionality entirely and focus efforts on improving regular typo correction. This removal fixes ~20 open issues (quite possibly more), improves compile time performance by roughly .3-.4% (https://llvm-compile-time-tracker.com/?config=Overview&stat=instructions%3Au&remote=AaronBallman&sortBy=date), and does not appear to regress diagnostic behavior in a way we wouldn't find acceptable. Fixes #142457 Fixes #139913 Fixes #138850 Fixes #137867 Fixes #137860 Fixes #107840 Fixes #93308 Fixes #69470 Fixes #59391 Fixes #58172 Fixes #46215 Fixes #45915 Fixes #45891 Fixes #44490 Fixes #36703 Fixes #32903 Fixes #23312 Fixes #69874
2025-05-15[C] Silence unreachable -Watomic-access diagnostics (#140064)Aaron Ballman1-1/+1
Accessing the member of a structure or union which is _Atomic-qualified is undefined behavior in C. We currently diagnose that with a warning that defaults to an error. In turn, this means we reject a valid program if the access it not reachable because of the error. e.g., if (0) SomeAtomicStruct.Member = 12; // Was diagnosed This silences the diagnostic if the member access is not reachable.
2025-05-02[clang][NFC] Convert `Sema::CorrectTypoKind` to scoped enumVlad Serebrennikov1-2/+2
2025-03-15[Clang] Do not emit nodiscard warnings for the base expr of static member ↵cor3ntin1-1/+0
access (#131450) For an expression `nodiscard_function().static_member(), the nodiscard warnings added by #120223, are not useful or actionable, and are disruptive to some library implementations; we just remove them. Fixes #131410
2025-03-11[HLSL] Make memory representation of boolean vectors in HLSL, vectors of ↵Sarah Spall1-1/+1
i32. Add support for boolean swizzling. (#123977) Make the memory representation of boolean vectors in HLSL, vectors of i32. Allow boolean swizzling for boolean vectors in HLSL. Add tests for boolean vectors and boolean vector swizzling. Closes #91639
2025-01-22Revert "Reapply "[Clang][Sema] Use the correct lookup context when building ↵Krystian Stasiowski1-1/+1
overloaded 'operator->' in the current instantiation (#104458)"" (#123982) Reverts llvm/llvm-project#109422
2025-01-22Reapply "[Clang][Sema] Use the correct lookup context when building ↵Krystian Stasiowski1-1/+1
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.
2024-12-20Fix double-quotes in diagnostic when attempting to access a ext_vector of ↵William Tran-Viet1-2/+5
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.
2024-12-18[Clang] Implement CWG2813: Class member access with prvalues (#120223)cor3ntin1-12/+55
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>
2024-11-26[Clang] Only ignore special methods for unused private fields in ↵Mészáros Gergely1-2/+10
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
2024-11-21[Clang] Prevent null dereferences (#115502)smanna121-1/+1
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.
2024-11-16[Sema] Remove unused includes (NFC) (#116461)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-08-06[Clang][Sema] Make UnresolvedLookupExprs in class scope explicit ↵Krystian Stasiowski1-1/+2
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.
2024-07-15Revert "Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)"Haojian Wu1-33/+41
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
2024-07-11Reapply "[Clang] Implement resolution for CWG1835 (#92957)" (#98547)Krystian Stasiowski1-41/+33
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.
2024-07-10Revert "[Clang] Implement resolution for CWG1835 (#92957)"NAKAMURA Takumi1-33/+41
ppc64le-lld-multistage-test has been failing. This reverts commit 7bfb98c34687d9784f36937c3ff3e735698b498a.
2024-07-09[Clang] Implement resolution for CWG1835 (#92957)Krystian Stasiowski1-41/+33
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.
2024-07-09[Clang][Sema] Handle class member access expressions with valid ↵Krystian Stasiowski1-10/+7
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`).
2024-07-01[clang][NFC] Move documentation of `Sema` functions into `Sema.h`Vlad Serebrennikov1-28/+0
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.
2024-05-29[clang] Preserve Qualifiers and type sugar in TemplateNames (#93433)Matheus Izvekov1-1/+2
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.
2024-05-13[clang] Introduce `SemaObjC` (#89086)Vlad Serebrennikov1-6/+6
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.
2024-05-13[Clang][Sema] Fix bug where operator-> typo corrects in the current ↵Krystian Stasiowski1-24/+25
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).
2024-05-09[Clang][Sema] Revert changes to operator= lookup in templated classes from ↵Krystian Stasiowski1-1/+4
#91498, #90999, and #90152 (#91620) This reverts changes in #91498, #90999, and #90152 which make `operator=` dependent whenever the current class is templated.
2024-04-30Reapply "[Clang][Sema] Diagnose class member access expressions naming ↵Krystian Stasiowski1-151/+119
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).
2024-04-26Revert "[Clang][Sema] Diagnose class member access expressions naming ↵Pranav Kant1-79/+103
non-existent members of the current instantiation prior to instantiation in the absence of dependent base classes (#84050)" This reverts commit a8fd0d029dca7d17eee72d0445223c2fe1ee7758.
2024-04-26Revert "[Clang][Sema] Fix warnings after #84050 (#90104)"Pranav Kant1-0/+1
This reverts commit 6dd2617c80d5133b92fdff679364f2d8fcd93b47.
2024-04-25[Clang][Sema] Fix warnings after #84050 (#90104)Krystian Stasiowski1-1/+0
2024-04-25[Clang][Sema] Diagnose class member access expressions naming non-existent ↵Krystian Stasiowski1-103/+79
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).
2024-04-22Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent class ↵Krystian Stasiowski1-15/+57
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.
2024-04-17[clang][NFC] Refactor `Sema::RedeclarationKind`Vlad Serebrennikov1-1/+1
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`.
2024-04-16[clang] Introduce `SemaOpenMP` (#88642)Vlad Serebrennikov1-4/+5
This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-04-15Revert "Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent ↵Mikhail Goncharov1-49/+14
class scope function template specialization that instantiates to a static member function (#87541)" (#88311)" This reverts commit aa80f3ec48419a73aafcc2ff947c6dd1e3734481. See https://github.com/llvm/llvm-project/pull/88311#issuecomment-2052291140. There is a fix forward proposed but I am reverting this commit to fix trunk.
2024-04-11Reapply "[Clang][Sema] Fix crash when 'this' is used in a dependent class ↵Krystian Stasiowski1-14/+49
scope function template specialization that instantiates to a static member function (#87541)" (#88311) Reapplies #87541 and addresses the bug which caused expressions naming overload sets to be incorrectly rebuilt.
2024-04-10Revert "[Clang][Sema] Fix crash when 'this' is used in a dependent class ↵Krystian Stasiowski1-30/+12
scope function template specialization that instantiates to a static member function" (#88264) Reverts llvm/llvm-project#87541
2024-04-09[Clang][Sema] Fix crash when 'this' is used in a dependent class scope ↵Krystian Stasiowski1-12/+30
function template specialization that instantiates to a static member function (#87541) This patch fixes a crash that happens when '`this`' is referenced (implicitly or explicitly) in a dependent class scope function template specialization that instantiates to a static member function. For example: ``` template<typename T> struct A { template<typename U> static void f(); template<> void f<int>() { this; // causes crash during instantiation } }; template struct A<int>; ``` This happens because during instantiation of the function body, `Sema::getCurrentThisType` will return a null `QualType` which we rebuild the `CXXThisExpr` with. A similar problem exists for implicit class member access expressions in such contexts (which shouldn't really happen within templates anyways per [class.mfct.non.static] p2, but changing that is non-trivial). This patch fixes the crash by building `UnresolvedLookupExpr`s instead of `MemberExpr`s for these implicit member accesses, which will then be correctly rebuilt as `MemberExpr`s during instantiation.
2024-01-11[clang]not lookup name containing a dependent type (#77587)Congcong Cai1-1/+2
Fixes: #77583 bcd51aaaf8bde4b0ae7a4155d9ce3dec78fe2598 fixed part of template instantiation dependent name issues but still missing some cases This patch want to enhance the dependent name check
2023-12-20[Clang] Fix a crash when incorrectly calling an explicit object member ↵cor3ntin1-1/+3
function template (#75913) Fixes #75732
2023-11-29[HLSL] Support vector swizzles on scalars (#67700)Chris B1-0/+10
HLSL supports vector swizzles on scalars by implicitly converting the scalar to a single-element vector. This syntax is a convienent way to initialize vectors based on filling a scalar value. There are two parts of this change. The first part in the Lexer splits numeric constant tokens when a `.x` or `.r` suffix is encountered. This splitting is a bit hacky but allows the numeric constant to be parsed separately from the vector element expression. There is an ambiguity here with the `r` suffix used by fixed point types, however fixed point types aren't supported in HLSL so this should not cause any exposable problems (a separate issue has been filed to track validating language options for HLSL: #67689). The second part of this change is in Sema::LookupMemberExpr. For HLSL, if the base type is a scalar, we implicit cast the scalar to a one-element vector then call back to perform the vector lookup. Fixes #56658 and #67511
2023-10-02[C++] Implement "Deducing this" (P0847R7)Corentin Jabot1-19/+46
This patch implements P0847R7 (partially), CWG2561 and CWG2653. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D140828
2023-09-05[HLSL] Cleanup support for `this` as an l-valueChris Bieneman1-14/+5
The goal of this change is to clean up some of the code surrounding HLSL using CXXThisExpr as a non-pointer l-value. This change cleans up a bunch of assumptions and inconsistencies around how the type of `this` is handled through the AST and code generation. This change is be mostly NFC for HLSL, and completely NFC for other language modes. This change introduces a new member to query for the this object's type and seeks to clarify the normal usages of the this type. With the introudction of HLSL to clang, CXXThisExpr may now be an l-value and behave like a reference type rather than C++'s normal method of it being an r-value of pointer type. With this change there are now three ways in which a caller might need to query the type of `this`: * The type of the `CXXThisExpr` * The type of the object `this` referrs to * The type of the implicit (or explicit) `this` argument This change codifies those three ways you may need to query respectively as: * CXXMethodDecl::getThisType() * CXXMethodDecl::getThisObjectType() * CXXMethodDecl::getThisArgType() This change then revisits all uses of `getThisType()`, and in cases where the only use was to resolve the pointee type, it replaces the call with `getThisObjectType()`. In other cases it evaluates whether the desired returned type is the type of the `this` expr, or the type of the `this` function argument. The `this` expr type is used for creating additional expr AST nodes and for member lookup, while the argument type is used mostly for code generation. Additionally some cases that used `getThisType` in simple queries could be substituted for `getThisObjectType`. Since `getThisType` is implemented in terms of `getThisObjectType` calling the later should be more efficient if the former isn't needed. Reviewed By: aaron.ballman, bogner Differential Revision: https://reviews.llvm.org/D159247
2023-05-23[NFC][CLANG] Fix static code analyzer concerns with dereference null return ↵Manna, Soumi1-1/+1
value Reported by Static Code Analyzer Tool, Coverity: Inside "SemaExprMember.cpp" file, in clang::Sema::BuildMemberReferenceExpr(clang::Expr *, clang::QualType, clang::SourceLocation, bool, clang::CXXScopeSpec &, clang::SourceLocation, clang::NamedDecl *, clang::DeclarationNameInfo const &, clang::TemplateArgumentListInfo const *, clang::Scope const *, clang::Sema::ActOnMemberAccessExtraArgs *): Return value of function which returns null is dereferenced without checking //Condition !Base, taking true branch. if (!Base) { TypoExpr *TE = nullptr; QualType RecordTy = BaseType; //Condition IsArrow, taking true branch. if (IsArrow) RecordTy = RecordTy->castAs<PointerType>()->getPointeeType(); //returned_null: getAs returns nullptr (checked 279 out of 294 times). //Condition TemplateArgs != NULL, taking true branch. //Dereference null return value (NULL_RETURNS) //dereference: Dereferencing a pointer that might be nullptr RecordTy->getAs() when calling LookupMemberExprInRecord. if (LookupMemberExprInRecord( *this, R, nullptr, RecordTy->getAs<RecordType>(), OpLoc, IsArrow, SS, TemplateArgs != nullptr, TemplateKWLoc, TE)) return ExprError(); if (TE) return TE; This patch uses castAs instead of getAs which will assert if the type doesn't match. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D151130
2023-03-17[clang] Fix two unused variable warnings from if statements. NFCCraig Topper1-1/+1
2023-03-14[Clang] Fix ClassifyImplicitMemberAccess to handle cases where the access in ↵Shafik Yaghmour1-2/+5
an unevaluated context is not within a CXXRecordDecl or CXXMethodDecl ClassifyImplicitMemberAccess assumes that if we are not in a static context then the DeclContext must be a CXXRecordDecl or a CXXMethodDecl. In the case of the unevaluated context this may not be true. This will lead to a crash because contextClass will remain a nullptr. Fixes: https://github.com/llvm/llvm-project/issues/37792 Fixes: https://github.com/llvm/llvm-project/issues/48405 Differential Revision: https://reviews.llvm.org/D142490
2022-11-15[Sema] Use the value category of the base expression when creating anAkira Hatanaka1-10/+1
ExtVectorElementExpr This fixes a bug where an lvalue ExtVectorElementExpr was created when the base expression was an ObjC property dot operator. This reverts 220d08d942ab0df3211388e602ed34fa6139ca61. Differential Revision: https://reviews.llvm.org/D138058
2022-11-07[HLSL] Added HLSL this as a referenceGrace Jennings1-0/+8
This change makes `this` a reference instead of a pointer in HLSL. HLSL does not have the `->` operator, and accesses through `this` are with the `.` syntax. Tests were added and altered to make sure the AST accurately reflects the types. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D135721
2022-09-21[clang] Fix missing template arguments in AST of access to member variable ↵Matheus Izvekov1-4/+4
template Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Differential Revision: https://reviews.llvm.org/D134295
2022-08-08[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-1/+1
With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-04-16Add some helpers to better check Scope's kind. NFCJun Zhang1-1/+1
Signed-off-by: Jun Zhang <jun@junz.org>
2022-04-14[HLSL] Pointers are unsupported in HLSLChris Bieneman1-0/+3
HLSL does not support pointers or references. This change generates errors in sema for generating pointer, and reference types as well as common operators (address-of, dereference, arrow), which are used with pointers and are unsupported in HLSL. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D123167
2022-03-30Don't diagnostic atomic object access as UB in an unevaluated contextAaron Ballman1-1/+2
We started diagnosing this situation with a more clear diagnostic message, but it was pointed out that unevaluated contexts don't really have the undefined behavior property as there is no runtime access involved. This augments the changes in https://reviews.llvm.org/D122656 to not diagnose in an unevaluated context.