Commit Graph

590 Commits

Author SHA1 Message Date
Kazu Hirata 17d4bd3d78 [clang] Fix bugprone argument comments (NFC)
Identified with bugprone-argument-comment.
2022-01-09 00:19:49 -08:00
Sam McCall 92417eaf33 [CodeCompletion] Signature help for braced constructor calls
Implementation is based on the "expected type" as used for
designated-initializers in braced init lists. This means it can deduce the type
in some cases where it's not written:

  void foo(Widget);
  foo({ /*help here*/ });

Only basic constructor calls are in scope of this patch, excluded are:
 - aggregate initialization (no help is offered for aggregates)
 - initializer_list initialization (no help is offered for these constructors)

Fixes https://github.com/clangd/clangd/issues/306

Differential Revision: https://reviews.llvm.org/D116317
2022-01-03 20:14:59 +01:00
Kazu Hirata d245f2e859 [clang] Use llvm::erase_if (NFC) 2021-10-17 13:50:29 -07:00
Sam McCall ece4e92085 [CodeComplete] Basic code completion for attribute names.
Only the bare name is completed, with no args.
For args to be useful we need arg names. These *are* in the tablegen but
not currently emitted in usable form, so left this as future work.

C++11, C2x, GNU, declspec, MS syntax is supported, with the appropriate
spellings of attributes suggested.
`#pragma clang attribute` is supported but not terribly useful as we
only reach completion if parens are balanced (i.e. the line is not truncated)

There's no filtering of which attributes might make sense in this
grammatical context (e.g. attached to a function). In code-completion context
this is hard to do, and will only work in few cases :-(

There's also no filtering by langopts: this is because currently the
only way of checking is to try to produce diagnostics, which requires a
valid ParsedAttr which is hard to get.
This should be fairly simple to fix but requires some tablegen changes
to expose the logic without the side-effect.

Differential Revision: https://reviews.llvm.org/D107696
2021-08-12 23:49:10 +02:00
Vassil Vassilev 11b47c103a Reland "[clang-repl] Implement partial translation units and error recovery."
Original commit message:

[clang-repl] Implement partial translation units and error recovery.

https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:

Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.

The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.

The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.

Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.

It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.

We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.

We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.

This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:

```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
            ^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```

Differential revision: https://reviews.llvm.org/D104918
2021-07-12 15:21:22 +00:00
Vassil Vassilev 5922f234c8 Revert "[clang-repl] Implement partial translation units and error recovery."
This reverts commit 6775fc6ffa.

It also reverts "[lldb] Fix compilation by adjusting to the new ASTContext signature."

This reverts commit 03a3f86071.

We see some failures on the lldb infrastructure, these changes might play a role
in it. Let's revert it now and see if the bots will become green.

Ref: https://reviews.llvm.org/D104918
2021-07-11 14:40:10 +00:00
Vassil Vassilev 6775fc6ffa [clang-repl] Implement partial translation units and error recovery.
https://reviews.llvm.org/D96033 contained a discussion regarding efficient
modeling of error recovery. @rjmccall has outlined the key ideas:

Conceptually, we can split the translation unit into a sequence of partial
translation units (PTUs). Every declaration will be associated with a unique PTU
that owns it.

The first key insight here is that the owning PTU isn't always the "active"
(most recent) PTU, and it isn't always the PTU that the declaration
"comes from". A new declaration (that isn't a redeclaration or specialization of
anything) does belong to the active PTU. A template specialization, however,
belongs to the most recent PTU of all the declarations in its signature - mostly
that means that it can be pulled into a more recent PTU by its template
arguments.

The second key insight is that processing a PTU might extend an earlier PTU.
Rolling back the later PTU shouldn't throw that extension away. For example, if
the second PTU defines a template, and the third PTU requires that template to
be instantiated at float, that template specialization is still part of the
second PTU. Similarly, if the fifth PTU uses an inline function belonging to the
fourth, that definition still belongs to the fourth. When we go to emit code in
a new PTU, we map each declaration we have to emit back to its owning PTU and
emit it in a new module for just the extensions to that PTU. We keep track of
all the modules we've emitted for a PTU so that we can unload them all if we
decide to roll it back.

Most declarations/definitions will only refer to entities from the same or
earlier PTUs. However, it is possible (primarily by defining a
previously-declared entity, but also through templates or ADL) for an entity
that belongs to one PTU to refer to something from a later PTU. We will have to
keep track of this and prevent unwinding to later PTU when we recognize it.
Fortunately, this should be very rare; and crucially, we don't have to do the
bookkeeping for this if we've only got one PTU, e.g. in normal compilation.
Otherwise, PTUs after the first just need to record enough metadata to be able
to revert any changes they've made to declarations belonging to earlier PTUs,
e.g. to redeclaration chains or template specialization lists.

It should even eventually be possible for PTUs to provide their own slab
allocators which can be thrown away as part of rolling back the PTU. We can
maintain a notion of the active allocator and allocate things like Stmt/Expr
nodes in it, temporarily changing it to the appropriate PTU whenever we go to do
something like instantiate a function template. More care will be required when
allocating declarations and types, though.

We would want the PTU to be efficiently recoverable from a Decl; I'm not sure
how best to do that. An easy option that would cover most declarations would be
to make multiple TranslationUnitDecls and parent the declarations appropriately,
but I don't think that's good enough for things like member function templates,
since an instantiation of that would still be parented by its original class.
Maybe we can work this into the DC chain somehow, like how lexical DCs are.

We add a different kind of translation unit `TU_Incremental` which is a
complete translation unit that we might nonetheless incrementally extend later.
Because it is complete (and we might want to generate code for it), we do
perform template instantiation, but because it might be extended later, we don't
warn if it declares or uses undefined internal-linkage symbols.

This patch teaches clang-repl how to recover from errors by disconnecting the
most recent PTU and update the primary PTU lookup tables. For instance:

```./clang-repl
clang-repl> int i = 12; error;
In file included from <<< inputs >>>:1:
input_line_0:1:13: error: C++ requires a type specifier for all declarations
int i = 12; error;
            ^
error: Parsing failed.
clang-repl> int i = 13; extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=13
clang-repl> quit
```

Differential revision: https://reviews.llvm.org/D104918
2021-07-11 10:23:41 +00:00
Melanie Blower aaba37187f [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-29 13:26:23 -04:00
Melanie Blower 1d85d0879a Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2dbe1c675f.
More buildbot failures
2021-06-28 15:47:21 -04:00
Melanie Blower 2dbe1c675f [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-28 15:09:53 -04:00
Melanie Blower 8815ef823c Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2c02b0c3f4.
buildbot fails
2021-06-28 12:42:59 -04:00
Melanie Blower 2c02b0c3f4 [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-28 12:26:53 -04:00
oToToT 14a7296c01
[clang][clangd] Avoid inconsistent target creation
As proposed in D97109, I tried to make target creation consistent in `clang` and `clangd` by replacing the original procedure with a single function introduced in D97493.

This also helps `clangd` works with CUDA, OpenMP, etc.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D98128
2021-04-06 23:23:34 +08:00
Duncan P. N. Exon Smith f4d02fbe41 Frontend: Take VFS and MainFileBuffer by reference in PrecompiledPreamble::CanReuse, NFC
Clarify that `PrecompiledPreamble::CanReuse` requires non-null arguments
for `VFS` and `MainFileBuffer`, taking them by reference instead of by
pointer.

Differential Revision: https://reviews.llvm.org/D91297
2021-01-25 17:50:56 -08:00
Argyrios Kyrtzidis b0e89906f5 [ASTReader] Allow controlling separately whether validation should be disabled for a PCH vs a module file
This addresses an issue with how the PCH preable works, specifically:

1. When using a PCH/preamble the module hash changes and a different cache directory is used
2. When the preamble is used, PCH & PCM validation is disabled.

Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date.

rdar://72611253

Differential Revision: https://reviews.llvm.org/D95159
2021-01-21 20:45:54 -08:00
Duncan P. N. Exon Smith c3ff9939bf Remove RemappedFiles param from ASTUnit::LoadFromASTFile, NFC
This parameter is always set to `None`. Remove it.

Differential Revision: https://reviews.llvm.org/D90889
2020-12-09 14:44:31 -08:00
Duncan P. N. Exon Smith 51f3432f4b Frontend: Clarify logic for using the preamble in ASTUnit::CodeComplete, almost NFC
Clarify the logic for using the preamble (and overriding the main file
buffer) in `ASTUnit::CodeComplete` by factoring out a couple of lambdas
(`getUniqueID` and `hasSameUniqueID`).  While refactoring the logic,
hoist the check for `Line > 1` and locally check if the filenames are
equal (both to avoid unnecessary `stat` calls) and skip copying out the
filenames to `std::string`.

Besides fewer calls to `stat`, there's no functionality change here.

Differential Revision: https://reviews.llvm.org/D91296
2020-12-08 12:52:17 -08:00
Duncan P. N. Exon Smith 99b823c2eb Frontend: Remove redundant call to CompilerInstance::setFileManager, NFC
`ASTUnit::Parse` sets up the `FileManager` earlier in the same function,
ensuring `ASTUnit::getFileManager()` matches `Clang->getFileManager()`.
Remove the later call to `setFileManager(getFileManager())` since it
does nothing.

Differential Revision: https://reviews.llvm.org/D90888
2020-12-03 16:10:59 -08:00
Ben Barham 5834996fef [Frontend] Add flag to allow PCM generation despite compiler errors
As with precompiled headers, it's useful for indexers to be able to
continue through compiler errors in dependent modules.

Resolves rdar://69816264

Reviewed By: akyrtzi

Differential Revision: https://reviews.llvm.org/D91580
2020-11-17 17:27:50 -08:00
Duncan P. N. Exon Smith cfde3edeae Frontend: Remove unused parameter from ASTUnit::LoadFromCompilerInvocationAction, NFC
Drop `IncludeBriefCommentsInCodeCompletion` since it is always `false`.

Differential Revision: https://reviews.llvm.org/D91295
2020-11-13 17:47:17 -05:00
Duncan P. N. Exon Smith 4c55c3b66d Frontend: Change ComputePreambleBounds to take MemoryBufferRef, NFC
Avoid requiring an actual MemoryBuffer in ComputePreambleBounds, when
a MemoryBufferRef will do just fine.

Differential Revision: https://reviews.llvm.org/D90890
2020-11-11 17:19:51 -05:00
LemonBoy fd14a1f6ff [clang][Frontend] Add missing error handling
Some early errors during the ASTUnit creation were not transferred to the `FailedParseDiagnostic` so when the code in `LoadFromCommandLine` swaps its content with the content of `StoredDiagnostics` they cannot be retrieved by the user in any way.

Reviewed By: andrewrk, dblaikie

Differential Revision: https://reviews.llvm.org/D78658
2020-10-22 14:14:19 -07:00
Duncan P. N. Exon Smith 51d1d585e5 clang/Frontend: Use MemoryBufferRef in FrontendInputFile (and remove SourceManager::getBuffer)
In order to drop the final callers to `SourceManager::getBuffer`, change
`FrontendInputFile` to use `Optional<MemoryBufferRef>`. Also updated
the "unowned" version of `SourceManager::createFileID` to take a
`MemoryBufferRef` (it now calls `MemoryBuffer::getMemBuffer`, which
creates a `MemoryBuffer` that does not own the buffer data).

Differential Revision: https://reviews.llvm.org/D89427
2020-10-20 13:35:46 -04:00
David Blaikie d9485dfbc1 ASTUnit::FileDecls: Use unique_ptr to simplify memory management 2020-04-28 17:59:45 -07:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Duncan P. N. Exon Smith 20d51b2f14 clang/Modules: Rename CompilerInstance::ModuleManager, NFC
Fix the confusing naming of `CompilerInstance::ModuleManager`.  This is
actually an instance of `ASTReader`, which contains an instance of
`ModuleManager`.  I have to assume there was a point in the past where
they were just one class, but it's been pretty confusing for a while.  I
think it's time to fix it.

The new name is `TheASTReader`; the annoying `The` prefix is so that we
don't shadow the `ASTReader` class.  I tried out `ASTRdr` but that
seemed less clear, and this choice matches `ThePCHContainerOperations`
just a couple of declarations below.

Also rename `CompilerInstance::getModuleManager` and
`CompilerInstance::createModuleManager` to `*ASTReader`, making some
cases of `getModuleManager().getModuleManager()` a little more clear.

https://reviews.llvm.org/D70583
2019-11-22 18:24:11 -08:00
Duncan P. N. Exon Smith f7170d17a8 clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFC
Remove some cognitive load by renaming clang/Serialization/Module.h to
clang/Serialization/ModuleFile.h, since it declares the ModuleFile
class.  This also makes editing a bit easier, since the basename of the
file no long conflicts with clang/Basic/Module.h, which declares the
Module class.  Also move lib/Serialization/Module.cpp to
lib/Serialization/ModuleFile.cpp.
2019-11-21 19:07:00 -08:00
Jan Korous f69c91780f [Support] Add overload writeFileAtomically(std::function Writer)
Differential Revision: https://reviews.llvm.org/D67424

llvm-svn: 371890
2019-09-13 20:08:27 +00:00
Evgeny Mankov 2ed2e62498 [preprocessor] Add an opportunity to retain excluded conditional blocks
It is handy for clang tooling, for instance, in source to source transformation.

Reviewers: vpykhtin (Valery Pykhtin), erichkeane (Erich Keane)

Subscribers: rsmith (Richard Smith), akyrtzi (Argyrios Kyrtzidis)

Tags: #clang

Differential Revision: https://reviews.llvm.org/D66597

llvm-svn: 370123
2019-08-27 22:15:32 +00:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
Benjamin Kramer e57b60f321 Replace non-recursive sys::Mutex users with std::mutex
Also remove a use of sys::MutexImpl, that's just evil. No functionality
change intended.

llvm-svn: 368157
2019-08-07 11:59:44 +00:00
Rainer Orth 09d890d728 Move LangStandard*, InputKind::Language to Basic
This patch is a prerequisite for using LangStandard from Driver in
https://reviews.llvm.org/D64793.

It moves LangStandard* and InputKind::Language to Basic.  It is mostly
mechanical, with only a few changes of note:

- enum Language has been changed into enum class Language : uint8_t to
  avoid a clash between OpenCL in enum Language and OpenCL in enum
  LangFeatures and not to increase the size of class InputKind.

- Now that getLangStandardForName, which is currently unused, also checks
  both canonical and alias names, I've introduced a helper getLangKind
  which factors out a code pattern already used 3 times.

The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11,
and x86_64-pc-linux-gnu.

There's a companion patch for lldb which uses LangStandard.h
(https://reviews.llvm.org/D65717).

While polly includes isl which in turn uses InputKind::C, that part of the
code isn't even built inside the llvm tree.  I've posted a patch to allow
for both InputKind::C and Language::C upstream
(https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE).

Differential Revision: https://reviews.llvm.org/D65562

llvm-svn: 367864
2019-08-05 13:59:26 +00:00
Harlan Haskins 8d323d1506 [clang] Adopt new FileManager error-returning APIs
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367616
2019-08-01 21:31:56 +00:00
Ilya Biryukov 5de0c85e88 [ASTUnit] Fix a regression in cached completions
Summary:
After r345152 cached completions started adding namespaces after
nested name specifiers, e.g. in `some_name::^`

The CCC_Symbol indicates the completed item cannot be a namespace (it is
described as being "a type, a function or a variable" in the comments).

Therefore, 'nested specifier' completions should only be added from cache
when the context is CCC_SymbolOrNewName (which roughly seems to indicate
that a nested name specifier is allowed).

Fixes https://bugs.llvm.org/show_bug.cgi?id=42646

Reviewers: kadircet, sammccall

Reviewed By: kadircet, sammccall

Subscribers: arphaman, nik, sammccall, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64918

llvm-svn: 366448
2019-07-18 15:21:34 +00:00
Francis Visoiu Mistrih e0308279cb [Bitcode] Move Bitstream to a separate library
This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.

This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.

Since Bitcode uses Core for the IR part:

libLLVMRemarks -> Bitcode -> Core

and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):

Core -> libLLVMRemarks

we need to separate the Bitstream and Bitcode part.

For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.

Differential Revision: https://reviews.llvm.org/D63899

llvm-svn: 365091
2019-07-03 22:40:07 +00:00
Fangrui Song 7264a474b7 Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or llvm::partition_point. NFC
llvm-svn: 365006
2019-07-03 08:13:17 +00:00
JF Bastien 0e82895826 BitStream reader: propagate errors
The bitstream reader handles errors poorly. This has two effects:

 * Bugs in file handling (especially modules) manifest as an "unexpected end of
   file" crash
 * Users of clang as a library end up aborting because the code unconditionally
   calls `report_fatal_error`

The bitstream reader should be more resilient and return Expected / Error as
soon as an error is encountered, not way late like it does now. This patch
starts doing so and adopting the error handling where I think it makes sense.
There's plenty more to do: this patch propagates errors to be minimally useful,
and follow-ups will propagate them further and improve diagnostics.

https://bugs.llvm.org/show_bug.cgi?id=42311
<rdar://problem/33159405>

Differential Revision: https://reviews.llvm.org/D63518

llvm-svn: 364464
2019-06-26 19:50:12 +00:00
Nikolai Kosjar 8edd8da487 [libclang] Allow skipping warnings from all included files
Depending on the included files and the used warning flags, e.g. -
Weverything, a huge number of warnings can be reported for included
files. As processing that many diagnostics comes with a performance
impact and not all clients are interested in those diagnostics, add a
flag to skip them.

Differential Revision: https://reviews.llvm.org/D48116

llvm-svn: 363067
2019-06-11 14:14:24 +00:00
Ilya Biryukov 2917526f29 [Frontend] Return an error on bad inputs to PrecompiledPreabmle
Summary:
Instead of failing with assertions. Fixes a crash found by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12865

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62137

llvm-svn: 361376
2019-05-22 12:50:01 +00:00
Nikolai Kosjar 295c19e948 [Preamble] Reuse preamble even if an unsaved file does not exist
When a preamble is created an unsaved file not existing on disk is
already part of PrecompiledPreamble::FilesInPreamble. However, when
checking whether the preamble can be re-used, a failed stat of such an
unsaved file invalidated the preamble, which led to pointless and time
consuming preamble regenerations on subsequent reparses.

Do not require anymore that unsaved files should exist on disk.

This avoids costly preamble invalidations depending on timing issues for
the cases where the file on disk might be removed just to be regenerated
a bit later.

It also allows an IDE to provide in-memory files that might not exist on
disk, e.g. because the build system hasn't generated those yet.

Differential Revision: https://reviews.llvm.org/D41005

llvm-svn: 361226
2019-05-21 07:26:59 +00:00
Sam McCall 3a75330f57 [CodeComplete] Remove obsolete isOutputBinary().
Summary:
It's never set to true. Its only effect would be to set stdout to binary mode.
Hopefully we have better ways of doing this by now :-)

Reviewers: hokein

Subscribers: jkorous, arphaman, kadircet, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D60871

llvm-svn: 358696
2019-04-18 17:35:55 +00:00
Duncan P. N. Exon Smith db8a742206 Basic: Return a reference from FileManager::getVirtualFileSystem, NFC
FileManager constructs a VFS in its constructor if it isn't passed one,
and there's no way to reset it.  Make that contract clear by returning a
reference from its accessor.

https://reviews.llvm.org/D59388

llvm-svn: 357038
2019-03-26 22:32:06 +00:00
Duncan P. N. Exon Smith 1da7eac87c Frontend: Remove CompilerInstance::VirtualFileSystem, NFC
Remove CompilerInstance::VirtualFileSystem and
CompilerInstance::setVirtualFileSystem, instead relying on the VFS in
the FileManager.  CompilerInstance and its clients already went to some
trouble to make these match.  Now they are guaranteed to match.

As part of this, I added a VFS parameter (defaults to nullptr) to
CompilerInstance::createFileManager, to avoid repeating construction
logic in clients that just wanted to customize the VFS.

https://reviews.llvm.org/D59377

llvm-svn: 357037
2019-03-26 22:18:52 +00:00
Duncan P. N. Exon Smith 8bef5cd49a Modules: Rename MemoryBufferCache to InMemoryModuleCache
Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to
Serialization.  Another patch will start using it to manage module build
more explicitly, but this is split out because it's mostly mechanical.

Because of the move to Serialization we can no longer abuse the
Preprocessor to forward it to the ASTReader.  Besides the rename and
file move, that means Preprocessor::Preprocessor has one fewer parameter
and ASTReader::ASTReader has one more.

llvm-svn: 355777
2019-03-09 17:33:56 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Richard Trieu f3b0046ba9 Move PCHContainerOperations from Frontend to Serialization
Fix a layering violation.  Frontend depends on Serialization, so anything used
by both should be in Serialization.

llvm-svn: 348907
2018-12-12 02:53:59 +00:00
Erik Pilkington fa98390b3c NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637
2018-10-30 20:31:30 +00:00
Kadir Cetinkaya b006e0995f [clang] Introduce new completion context types
Summary: New name suggestions were being used in places where existing names should have been used, this patch tries to fix some of those situations.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: arphaman, cfe-commits

Differential Revision: https://reviews.llvm.org/D53191

llvm-svn: 345152
2018-10-24 15:23:49 +00:00
Jonas Devlieghere fc51490baf Lift VFS from clang to llvm (NFC)
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.

Concretely the patch:
 - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
 - Moves the corresponding unit test from clang to llvm.
 - Moves the vfs namespace from clang::vfs to llvm::vfs.
 - Formats the lines affected by this change, mostly this is the result of
   the added llvm namespace.

RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html

Differential revision: https://reviews.llvm.org/D52783

llvm-svn: 344140
2018-10-10 13:27:25 +00:00
Sam McCall 3d8051abb8 [CodeComplete] Add completions for filenames in #include directives.
Summary:
The dir component ("somedir" in #include <somedir/fo...>) is considered fixed.
We append "foo" to each directory on the include path, and then list its files.

Completions are of the forms:
 #include <somedir/fo^
                   foo.h>
                   fox/

The filter is set to the filename part ("fo"), so fuzzy matching can be
applied to the filename only.

No fancy scoring/priorities are set, and no information is added to
CodeCompleteResult to make smart scoring possible. Could be in future.

Reviewers: ilya-biryukov

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D52076

llvm-svn: 342449
2018-09-18 08:40:41 +00:00