Sublime Forum

Clang (C/C++/Objective-C/Objective-C++) autocomplete

#81

I’ve opened an issue for this on the SublimeClang homepage: github.com/quarnster/SublimeClang/issues/54

BTW, you can toggle the plugin on and off via the default keybinding alt+d,alt+t.

0 Likes

#82

This has now been fixed.

0 Likes

#83

Great! Thanks for the super quick fix!

0 Likes

#84

I’ve been reading through this thread and am still wondering if there is a definitive answer on whether or not clang autocomplete works properly on Windows 64 Sublime 2 using MinGW for C++ STL. I have the following in my User Options for SublimeClang:

[code]{
“options”:

    "-Wall",
    "-IC:\\MinGW\\include",
    "-IC:\\MinGW\\lib",
    "-IC:\\MinGW\\lib\\gcc\\mingw32\\4.6.2\\include\\c++",
    "-IC:\\MinGW\\lib\\gcc\\mingw32\\4.6.2\\include\\c++\\mingw32"
]

}
[/code]

and while it looks like the plugin is doing something, I keep getting the following error:

C:\MinGW\include\wchar.h:26,10 - Fatal - ‘stddef.h’ file not found

stddef.h is sitting in C:\MinGW\lib\gcc\mingw32\4.6.2\include and when I alter the options to include that directory, the previous error goes and I am confronted with:

C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:145,11 - Error - no member named ‘fgetws’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:147,11 - Error - no member named ‘fputws’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:151,11 - Error - no member named ‘getwc’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:152,11 - Error - no member named ‘getwchar’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:157,11 - Error - no member named ‘putwc’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\cwchar:158,11 - Error - no member named ‘putwchar’ in the global namespace
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\bits/basic_ios.h:249,26 - Error - expected ‘)’
C:\MinGW\lib\gcc\mingw32\4.6.2\include\c++\bits/basic_ios.h:249,17 - Note - to match this ‘(’

Any suggestions would be greatly appreciated.

0 Likes

#85

I’ve found a problem that if in my sublimeclang_options I include a directory with a large number of files (1249 to be exact), sublime crashes with the following error:

https://dl.dropbox.com/u/427616/crash.png

I happen to have VS10 installed, and this is the assertion in question:

_Myiter& operator++()
		{	// preincrement
 #if _ITERATOR_DEBUG_LEVEL == 2
		if (this->_Getcont() == 0
			|| this->_Ptr == 0
			|| ((_Myvec *)this->_Getcont())->_Mylast <= this->_Ptr)
			{	// report error
			_DEBUG_ERROR("vector iterator not incrementable");
			_SCL_SECURE_OUT_OF_RANGE;
			}

The Sublime console shows the following after the crash:

Exception AttributeError: "Cache instance has no attribute 'cache'" in <bound method Cache.__del__ of <translationunitcache.Cache instance at 0x000000000552F808>> ignored
Traceback (most recent call last):
  File ".\common.py", line 173, in worker
  File ".\translationunitcache.py", line 723, in task_reparse
  File ".\translationunitcache.py", line 849, in get_translation_unit
  File ".\translationunitcache.py", line 640, in __init__
  File ".\translationunitcache.py", line 108, in __init__
WindowsError: [Error -2147483645] One or more arguments are invalid

Sublime itself doesn’t crash until I click ‘abort’, so I’m actually guessing the assertion is actually in libclang.dll.
This is with ST 2181 (Windows obviously).

Thanks.

0 Likes

#86

I’ve opened up a new issue on github for this. Is your code base shareable so that I can get a copy of what you are seeing? If not, do you have a small test where this reproduces? Otherwise it’s unlikely to be fixed from my side as I don’t code on Windows and it’s not something I’ve seen from my limited testing on Windows.

0 Likes

#87

Thanks. I’m not able to share the codebase I’m working on, but I’ll try to reproduce the problem with test code. Barring that, I can help debug it a bit for you if you have some things you’d like me to try.

0 Likes

#88

I had a quick play with this yesterday on windows and was getting lockups

I seem to recall reading that clang hardcodes visual studio/mingw paths?

Does anyone know if it’s possible to steer it towards sources on a linux vm?

0 Likes

#89

castles_made_of_sand, if your lockups are the same as RyanJ’s then maybe it has been fixed now. You could disable all the standard includes via “-nostdinc”. As long as the vm sources are available as a windows file path you should be able to steer it that way.

RyanJ, I think your issue has been fixed. As issue 74 hasn’t been fixed yet, could you use package control to remove SublimeClang, quit Sublime Text 2, delete the SublimeClang package folder and then re-install it via Package Control and see if the issue is gone now please?

0 Likes

#90

Awesome :smile: Thanks. I’ll give it a crack.

0 Likes

#91

So, I just got a lockup, the console was open and there was a traceback:

[code]Traceback (most recent call last):

File ".\sublimeclang.py", line 553, in recompile
File ".\translationunitcache.py", line 776, in reparse
File ".\translationunitcache.py", line ???, in get_opts_script
File ".\common.py", line 82, in expand_path

TypeError: unsupported operand type(s) for %: ‘NoneType’ and ‘dict’
[/code]

(FFFF I just typed that in by hand and seem to have fucked up one of the line numbers :smile:)

Dunno how it’s related to the lockup, but that 's the last bit info in the console.

0 Likes

#92

From a superficial look, not really understanding the why/what/how of the locking , I can see a lack of try/finally with some uses of the locks, so an exception will mean the lock doesn’t get released.

Seems like it’s a dictlike.get(key, None) % dict() situation

Will take a look

0 Likes

#93

Ah, using a Lock() instead of a reentrant lock, which if you grab in the same thread again, won’t cause these locks.

I made a 1 character change to RLock and that same exception no longer causes the freeze.

Traceback (most recent call last): File ".\sublimeclang.py", line 553, in recompile File ".\translationunitcache.py", line 776, in reparse File ".\translationunitcache.py", line 806, in get_opts_script File ".\common.py", line 82, in expand_path TypeError: unsupported operand type(s) for %: 'NoneType' and 'dict'

I’ll patch LockedVariable to make it a context manager.

0 Likes

#94

Is there any way to get contextually aware auto completion?

For example, say I have my cursor, represented as “|”, inside #include <|, I’m getting completion choices for macros and what have you.

0 Likes

#95

You can disable the fast completions with alt+d,alt+f which will then fall back to clang’s built in autocomplete functionality which is more accurate but slower.

0 Likes

#96

Sweet, cheers :smiley:

I’ll be sending you some paypal love when I have some credit.

I’ve been getting paid cash via western union so nothing in the pig atm :unamused:

0 Likes

#97

How did you end up in the situation where options_script is None anyway? Because by default it’s set to “” so wouldn’t trigger this issue…

09:11 /tmp/SublimeClang $ curl -O http://cloud.github.com/downloads/quarnster/SublimeClang/SublimeClang.sublime-package % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 11.1M 100 11.1M 0 0 4207k 0 0:00:02 0:00:02 --:--:-- 4330k 09:11 /tmp/SublimeClang $ unzip SublimeClang.sublime-package Archive: SublimeClang.sublime-package inflating: Context.sublime-menu inflating: Default.sublime-commands inflating: Default.sublime-keymap inflating: Main.sublime-menu inflating: README.creole inflating: SublimeClang.sublime-settings creating: clang/ inflating: clang/__init__.py inflating: clang/cindex.py creating: clang/include/ inflating: clang/include/altivec.h inflating: clang/include/arm_neon.h inflating: clang/include/avxintrin.h inflating: clang/include/emmintrin.h inflating: clang/include/float.h inflating: clang/include/immintrin.h inflating: clang/include/iso646.h inflating: clang/include/limits.h inflating: clang/include/mm3dnow.h inflating: clang/include/mm_malloc.h inflating: clang/include/mmintrin.h inflating: clang/include/nmmintrin.h inflating: clang/include/pmmintrin.h inflating: clang/include/smmintrin.h inflating: clang/include/stdalign.h inflating: clang/include/stdarg.h inflating: clang/include/stdbool.h inflating: clang/include/stddef.h inflating: clang/include/stdint.h inflating: clang/include/tgmath.h inflating: clang/include/tmmintrin.h inflating: clang/include/varargs.h inflating: clang/include/wmmintrin.h inflating: clang/include/x86intrin.h inflating: clang/include/xmmintrin.h inflating: common.py inflating: errormarkers.py inflating: libcache.dll inflating: libcache.dylib inflating: libcache_x64.dll inflating: libclang.dll inflating: libclang.dylib inflating: libclang_x64.dll inflating: package.json creating: parsehelp/ extracting: parsehelp/__init__.py inflating: parsehelp/parsehelp.py creating: src/ creating: src/clang-c/ inflating: src/clang-c/Index.h inflating: src/CMakeLists.txt inflating: src/main.cpp inflating: staticanalyzer.py inflating: sublimeclang.py inflating: sublimeclang.sublime-project inflating: translationunitcache.py 09:11 /tmp/SublimeClang $ cat SublimeClang.sublime-settings | grep options_script "options_script": "", 09:11 /tmp/SublimeClang $

The right fix is to do try finally blocks as there shouldn’t be a need for reentrance. I’ll patch this up.

0 Likes

#98
return expand_path(get_setting("options_script", None, view), view.window())

I think after nuking/recloning fresh I just rewound the history on the settings file using a backups plugin. The keys must have changed.

I’ll revert it to make sure I have all the latest settings.

Yeah, I just changed it to use RLock as it was a quick 1 character fix to stop it locking so I could take a look at the code.

I don’t like editing in notepad LOL

Context managers, ie with blocks, are nice for that. Saves having try/finally every where.

0 Likes

#99

Thanks, no luck though. I’ve tried making a test project with the same include paths, but the error is sporadic. I don’t think that the one path which caused the error before is really the issue – it seems to be something else which happened to be triggered in this case.

I printed out the filename & opts in translationunitcache.py in the parse/reparse functions, but nothing seemed unusual.

0 Likes

#100

RyanJ, You could compile libcache (and possibly libclang too) yourself with debug symbols enabled, and you should be able to attach a debugger to Sublime Text 2 and get a proper stacktrace for this issue.

0 Likes