[cfe-users] Trouble with clang::SourceManager and clang::ASTUnit

2016-12-12 Thread via cfe-users

Hi all,

I'm writing an auto-completion plug-in for Sublime Text 3 with a 
compiled component in C++. The compiled component is written as a clang 
tool living in llvm/tools/clang/tools/ and it links with the 
clangFrontend library. The bridge between Sublime's Python interface and 
C++ is pybind11.
So, for every suitable open buffer in Sublime I have a clang::ASTUnit 
fetching completions for it. The preamble of each file definitely needs 
to be precompiled otherwise fetching completions is too slow for serious 
use.


When I construct a clang::ASTUnit via 
ASTUnit::LoadFromCompilerInvocation (I build the invocation myself), and 
I choose the parameter PrecompilePreambleAfterNParses to be 1, then I 
sometimes get an assertion error involving clang::SourceManager, saying 
that two SourceLocations don't come from the same SourceManager.


I don't know how to fix this problem, as I cannot pass my own 
SourceManager anywhere. And it happens during construction of an 
ASTUnit, so I cannot re-arrange calls anywhere. If anyone has an idea as 
to what causes this then I'd be very interested, because I can't 
continue developing this plugin unless I fix this issue.


I have found out that if I set PrecompilePreambleAfterNParses to 0, 
everything seems to work fine. So, I'm guessing it has something to do 
with precompiling the preamble somehow. The full stack trace of the 
assertion error is below. If someone needs more info like local 
variables I can provide that too.


Regards,

Raoul Wols

* thread #6: tid = 0x6aed, 0x7fffbeb0edda 
libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
  * frame #0: 0x7fffbeb0edda libsystem_kernel.dylib`__pthread_kill 
+ 10
frame #1: 0x7fffbebfa787 libsystem_pthread.dylib`pthread_kill + 
90

frame #2: 0x7fffbea74420 libsystem_c.dylib`abort + 129
frame #3: 0x7fffbea3b893 libsystem_c.dylib`__assert_rtn + 320
frame #4: 0x00010e98b63e 
Clara.so`clang::FullSourceLoc::isBeforeInTranslationUnitThan(this=0x7406f3f8, 
Loc=FullSourceLoc @ 0x7406f240) const + 174 at 
SourceLocation.h:319
frame #5: 0x00010e997cec 
Clara.so`clang::DiagnosticsEngine::DiagStatePoint::operator<(clang::DiagnosticsEngine::DiagStatePoint 
const&) const(this=0x7406f3f0, RHS=0x7f886218a2f0) + 140 at 
Diagnostic.h:245
frame #6: 0x00010e997bd4 
Clara.so`std::__1::__wrap_iter 
std::__1::__upper_boundclang::DiagnosticsEngine::DiagStatePoint>&, 
std::__1::__wrap_iter, 
clang::DiagnosticsEngine::DiagStatePoint>(std::__1::__wrap_iter, 
std::__1::__wrap_iter, 
clang::DiagnosticsEngine::DiagStatePoint const&, 
std::__1::__lessclang::DiagnosticsEngine::DiagStatePoint>&) [inlined] 
std::__1::__lessclang::DiagnosticsEngine::DiagStatePoint>::operator(this=0x7406f4e8, 
__x=0x7406f3f0, 
__y=0x7f886218a2f0)(clang::DiagnosticsEngine::DiagStatePoint const&, 
clang::DiagnosticsEngine::DiagStatePoint const&) const + 436 at 
algorithm:702
frame #7: 0x00010e997bc7 
Clara.so`std::__1::__wrap_iter 
std::__1::__upper_boundclang::DiagnosticsEngine::DiagStatePoint>&, 
std::__1::__wrap_iter, 
clang::DiagnosticsEngine::DiagStatePoint>(__first=__wrap_iter*> @ 0x7406f2f8, 
__last=__wrap_iter @ 
0x7406f2f0, __value_=0x7406f3f0, 
__comp=0x7406f4e8) + 423 at algorithm:4180
frame #8: 0x00010e98b51d 
Clara.so`clang::DiagnosticsEngine::GetDiagStatePointForLoc(clang::SourceLocation) 
const [inlined] 
std::__1::__wrap_iter 
std::__1::upper_bound, 
clang::DiagnosticsEngine::DiagStatePoint, 
std::__1::__lessclang::DiagnosticsEngine::DiagStatePoint> 
>(__first=__wrap_iter @ 
0x7406f4f8, 
__last=__wrap_iter @ 
0x7406f4f0, __value_=0x7406f3f0, 
__comp=__lessclang::DiagnosticsEngine::DiagStatePoint> @ 0x7406f4e8) + 54 at 
algorithm:4202
frame #9: 0x00010e98b4e7 
Clara.so`clang::DiagnosticsEngine::GetDiagStatePointForLoc(clang::SourceLocation) 
const [inlined] 
std::__1::__wrap_iter 
std::__1::upper_bound, 
clang::DiagnosticsEngine::DiagStatePoint>(__first=__wrap_iter*> @ 0x7406f4c0, 
__last=__wrap_iter @ 
0x7406f4b8, __value_=0x7406f3f0) + 70 at algorithm:4211
frame #10: 0x00010e98b4a1 
Clara.so`clang::DiagnosticsEngine::GetDiagStatePointForLoc(this=0x7f8861189e00, 
L=(ID = 825)) const + 1537 at Diagnostic.cpp:177
frame #11: 0x00010e99cb6e 
Clara.so`clang::DiagnosticIDs::getDiagnosticSeverity(this=0x7f886009f390, 
DiagID=930, Loc=(ID = 825), Diag=0x7f8861189e00) const + 126 at 
DiagnosticIDs.cpp:415
frame #12: 0x00010e904921 
Clara.so`clang::DiagnosticsEngine::isIgnored(this=0x7f8861189e00, 
DiagID=930, Loc=(ID = 825)) const + 65 at Diagnostic.h:652
frame #13: 0x00010e8e32aa 
Clara.so`clang::Preprocessor::HandleDefineDirective(this=0x7f886367e200, 
DefineTok=0x7f8862810610, ImmediatelyAfterHeaderGuard=false) + 4170 
at PPDirectives.cpp:2546
frame #14: 0x00010e8daf9

[cfe-users] objc. __auto_type and nullablility inheritance.

2016-12-12 Thread Alfred Zien via cfe-users
Hi to everyone! I'm integrating __auto_type to project, and I faced with some 
weird issue. 

__auto_type doesn't inherit nullability nor ownership qualifiers, so if I write

__weak Type* _Nonnull a = f();
__auto_type b = a;

b will be just Type*, with strong ownership and __nullability_unspecified 
specifier.

Although, if I'm writing

__weak Type* _Nonnull a = f();
__typeof(a) b = a;

Everything inherits as expected. So type of b is __weak Type* _Nonnull.
I know, __weak and _Nullable doesn't make any sense for one variable 
declaration, but I think you get the point.

Is it ok? Why such decision has been made?
Thanks for any clarification.___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users