Summary:
This would allow code completion clients to know which context is visited during Sema code completion.
Also some changes:
* add `EnteredContext` callback in VisibleDeclConsumer.
* add a simple unittest for sema code completion (only for visited contexts at the moment).
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, bkramer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42071
llvm-svn: 322661
Summary:
noload_lookups() was too lazy: in addition to avoiding external decls, it
avoided populating the lazy lookup structure for internal decls.
This is the right behavior for the existing callsite in ASTDumper, but I think
it's not a very useful default, so we populate it by default.
While here:
- remove an unused test file accidentally added in r322371.
- remove lookups_begin()/lookups_end() in favor of lookups().begin(), which is
more common and more efficient.
Reviewers: ilya-biryukov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D42077
llvm-svn: 322548
Summary:
Enumerating the contents of a namespace or global scope will omit any
decls that aren't already loaded, instead of deserializing them from the
PCH.
This allows a fast hybrid code completion where symbols from headers are
provided by an external index. (Sema already exposes the information
needed to do a reasonabl job of filtering them).
Clangd plans to implement this hybrid.
This option is just a hint - callers still need to postfilter results if
they want to *avoid* completing decls outside the main file.
Reviewers: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41989
llvm-svn: 322371
redecl chain for an imported declaration, make sure to check the IDNS of prior
imported decls.
Otherwise we can end up finding an invisible friend declaration and incorrectly
believing that it should be visible.
llvm-svn: 321916
They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.
llvm-svn: 316965
It's possible for the code completion consumer to add new decls to the
current scope while lookup happens on it. Avoid this by making a copy
first.
Sadly I wasn't able to get a self-contained test case for this as it
requires code completion + precompiled preamble + the stars aligning to
deserialize at exactly the right time.
llvm-svn: 315772
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
C++14 added user-defined literal support for complex numbers so that you
can write something like "complex<double> val = 2i". However, there is
an existing GNU extension supporting this syntax and interpreting the
result as a _Complex type.
This changes parsing so that such literals are interpreted in terms of
C++14's operators if an overload is present but otherwise falls back to
the original GNU extension.
(We now have more robust diagnostics for implicit conversions so the
libc++ test that caused the original revert still passes).
llvm-svn: 310478
Summary:
Previously Clang was not considering operator declarations that occur at function scope. This is incorrect according to [over.match.oper]p3
> The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls.
This patch changes operator name lookup to consider block scope declarations.
This patch fixes PR27027.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D35297
llvm-svn: 309530
These cases occur frequently for declarations in the global module (above the
module-declaration) in a Modules TS module interface. When we merge a
definition from another module into such a module-private definition, ensure
that we transitively make everything lexically within that definition visible
to that translation unit.
llvm-svn: 307129
declarations that are owned but unconditionally visible.
This allows us to set declarations as visible even if they have a local owning
module, without losing information. In turn, that means that our Objective-C
support can keep on incorrectly assuming the "hidden" bit on the declaration is
the whole story with regard to name visibility. This will also be useful once
we support the C++ Modules TS export semantics.
Objective-C name visibility is still incorrect in any case where the "hidden"
bit is not the complete story: for instance, in Objective-C++ the set of
visible categories will be wrong during template instantiation, and with local
submodule visibility enabled it will be wrong when building modules. Fixing that
will require a major overhaul of how visibility is handled for Objective-C (and
particularly for categories).
llvm-svn: 306075
As the bug report says,
struct A
{
template<typename T> operator T();
};
void foo()
{
A().operator auto();
}
causes: "undeduced type in IR-generation
UNREACHABLE executed at llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:208!"
The problem is that in this case, "T" is being deduced as "auto",
which I believe is incorrect.
The 'operator auto' implementation in Clang is standards compliant, however
there is a defect report against core (1670).
Differential Revision: https://reviews.llvm.org/D34370
llvm-svn: 305812
replaced by visible decls.
Make sure that all paths through checkCorrectionVisibility set the
RequiresImport flag appropriately, so we don't end up using a stale value.
Patch by Jorge Gorbe!
Differential Revision: https://reviews.llvm.org/D30963
llvm-svn: 304745
We currenltly assert when want to diagnose a missing import and the decl
in question is already visible. It turns out that the decl in question
might be visible because another decl from the same module actually made
the module visible in a previous error diagnostic.
Remove the assertion and avoid re-exporting the module if it's already
visible.
rdar://problem/27975402
Differential Revision: https://reviews.llvm.org/D32828
llvm-svn: 303705
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
llvm-svn: 303469
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
This reinstates r302965, reverted in r303037, with a fix for the reported
crash, which occurred when reparenting a local declaration to be a child of
a hidden imported declaration (specifically during template instantiation).
llvm-svn: 303224
module immediately
Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.
llvm-svn: 303037
rather than waiting until it's queried.
Currently this is only applied to local submodule visibility mode, as we don't
yet allocate storage for the owning module in non-local-visibility modules
compilations.
llvm-svn: 302965
When we parse a redefinition of an entity for which we have a hidden existing
declaration, make it visible in the current module instead of mapping the
current source location to its containing module.
llvm-svn: 302842
type is a TemplateSpecializationType or InjectedClassNameType
Fixes PR30847. Partially fixes PR20973 (first position only).
PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.
rdar://29818301
llvm-svn: 302797
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
This reinstates r300650, reverted in r300659, with a fix for a regression
reported by Chandler after commit.
llvm-svn: 300938
modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.
Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged template.
llvm-svn: 300659
When looking for the template instantiation pattern of a templated entity,
consistently select the definition of the pattern if there is one. This means
we'll pick the same owning module when we start instantiating a template that
we'll later pick when determining which modules are visible during that
instantiation.
llvm-svn: 300650
such guides below explicit ones, and ensure that references to the class's
template parameters are not treated as forwarding references.
We make a few tweaks to the wording in the current standard:
1) The constructor parameter list is copied faithfully to the deduction guide,
without losing default arguments or a varargs ellipsis (which the standard
wording loses by omission).
2) If the class template declares no constructors, we add a T() -> T<...> guide
(which will only ever work if T has default arguments for all non-pack
template parameters).
3) If the class template declares nothing that looks like a copy or move
constructor, we add a T(T<...>) -> T<...> guide.
#2 and #3 follow from the "pretend we had a class type with these constructors"
philosophy for deduction guides.
llvm-svn: 295007
This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)
This fixes PR31638, PR31639, and PR31640.
Differential Revision: https://reviews.llvm.org/D28889
llvm-svn: 293360
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
llvm-svn: 291418
This can be used to append alternative typo corrections to an existing diag.
include-fixer can use it to suggest includes to be added.
Differential Revision: https://reviews.llvm.org/D26745
llvm-svn: 287128
The exact same test guards entry into the loop in which this test
occurs, and there is nothing inside the loop that assigns to the
variable, so it has already been checked for null.
This was flagged by PVS-Studio as well, but the report is actually wrong
-- this is not a case where we dereference a variable prior to testing
it for null, this is a case where we have a redundant test for null
after we already performed the exact same test.
llvm-svn: 285983
In C mode, if we have a visible declaration but not a visible definition, a tag
defined in the declaration should be have a visible definition. In C++ we rely
on the ODR merging, whereas in C we cannot because each declaration of a
function gets its own set of declarations in its prototype scope.
Patch developed in collaboration with Richard Smith!
llvm-svn: 280984
Haojian Wu