std::vector< Diagnostic > TranslationUnit::Reparse(
const std::vector< UnsavedFile > &unsaved_files ) {
std::vector< CXUnsavedFile > cxunsaved_files =
ToCXUnsavedFiles( unsaved_files );
Reparse( cxunsaved_files );
unique_lock< mutex > lock( diagnostics_mutex_ );
return latest_diagnostics_;
}
std::vector< CompletionData > TranslationUnit::CandidatesForLocation(
const std::string &filename,
int line,
int column,
const std::vector< UnsavedFile > &unsaved_files ) {
unique_lock< mutex > lock( clang_access_mutex_ );
if ( !clang_translation_unit_ ) {
return std::vector< CompletionData >();
}
std::vector< CXUnsavedFile > cxunsaved_files =
ToCXUnsavedFiles( unsaved_files );
const CXUnsavedFile *unsaved = cxunsaved_files.empty()
? nullptr : &cxunsaved_files[ 0 ];
// codeCompleteAt reparses the TU if the underlying source file has changed on
// disk since the last time the TU was updated and there are no unsaved files.
// If there are unsaved files, then codeCompleteAt will parse the in-memory
// file contents we are giving it. In short, it is NEVER a good idea to call
// clang_reparseTranslationUnit right before a call to clang_codeCompleteAt.
// This only makes clang reparse the whole file TWICE, which has a huge impact
// on latency. At the time of writing, it seems that most users of libclang
// in the open-source world don't realize this (I checked). Some don't even
// call reparse*, but parse* which is even less efficient.
CodeCompleteResultsWrap results(
clang_codeCompleteAt( clang_translation_unit_,
filename.c_str(),
line,
column,
const_cast<CXUnsavedFile *>( unsaved ),
cxunsaved_files.size(),
CompletionOptions() ),
clang_disposeCodeCompleteResults );
std::vector< CompletionData > candidates = ToCompletionDataVector(
results.get() );
return candidates;
}
