hidden definition with a would-be-parsed redefinition.
This permits a bunch of cleanups. In particular, we no longer need to
take merged definitions into account when checking declaration
visibility, only when checking definition visibility, which makes
certain visibility checks take linear instead of quadratic time.
We could also now remove the UPD_DECL_EXPORTED update record and track
on each declaration whether it was demoted from a definition (as we
already do for variables), but I'm not doing that in this patch to keep
the changes here simpler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@342018 91177308-0d34-0410-b5e6-96231b3b80d8
edit_distance returns UpperBound+1 if the distance will exceed UpperBound. We can subtract 1 from UpperBound and change >= to > in the if condition. The threshold does not change but edit_distance will have more opportunity to bail out earlier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@341763 91177308-0d34-0410-b5e6-96231b3b80d8
BindingDecls have null type until their initializer is processed, so we can't
assume that a correction candidate has non-null type.
rdar://41559582
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336634 91177308-0d34-0410-b5e6-96231b3b80d8
Previous, if no Decl's were checked, visibility was set to false. Switch it
so that in cases of no Decl's, return true. These are the Decl's after being
filtered. Also remove an unreachable return statement since it is directly
after another return statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334160 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331834 91177308-0d34-0410-b5e6-96231b3b80d8
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328636 91177308-0d34-0410-b5e6-96231b3b80d8
This relands r326965.
There was a null dereference in typo correction that was triggered in
Sema/diagnose_if.c. We are not always in a function scope when doing
typo correction. The fix is to add a null check.
LLVM's optimizer made it hard to find this bug. I wrote it up in a
not-very-well-editted blog post here:
http://qinsb.blogspot.com/2018/03/ub-will-delete-your-null-checks.html
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327334 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322661 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322548 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322371 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321916 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316965 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation, follow lexical parents not semantic ones: we want to find the
module where the pattern was written.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316055 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315772 91177308-0d34-0410-b5e6-96231b3b80d8
We want to check whether the using (shadow) declaration itself is visible, not
whether its target is visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315408 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315379 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315251 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310478 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309530 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307129 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306075 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305812 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304745 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r303697. It broke libc++ tests that were specifically
checking incompatibility in C++14 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303813 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303705 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303694 91177308-0d34-0410-b5e6-96231b3b80d8
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303469 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303322 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303224 91177308-0d34-0410-b5e6-96231b3b80d8
module immediately
Also revert dependent r302969. This is leading to crashes.
Will provide more details reproduction instructions to Richard.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303037 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302965 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302842 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302797 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300938 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300659 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300650 91177308-0d34-0410-b5e6-96231b3b80d8
using it for other kinds of context (where we currently produce context notes
in a highly ad-hoc manner).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295919 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith