ensisoft / sublimeclang Goto Github PK

• typed enums
• aliased types created by "using"
• auto
• what else?

Create a new window, write code like

int main()
{
return 0;
}

hit Save. The process hangs. Looks like an infinite loop inside the plugin.

Stack overflow error during reparse on win32. Currently no idea what is causing it.

Functions that are in the global namespace do not complete or provide suggestions.

Go to declaration and/or definition appears to go into an infinite loop, or then just takes a very long time to complete. Either case this is not acceptable.

The compile arguments appear to be incorrect sometimes. Plugin defined arguments are not passed to the frontend.

Currently in order to make things work manual work is required to figure out the right -isystem parameters. This is done by
$ clang++ -### -c test.cpp
which then prints a bunch of parameters. Currently we're interested in the -isystem paths
(listed as -internal-isystem) in the output. Seems that there might be a way to automate. Maybe we can ask clang/gcc for some of this information?

Hey,

quarnster's SublimeClang somehow support ST3 (python 3 support).
Looking at the code it seems that you removed various import check for python3.

e.g. :

• https://github.com/quarnster/SublimeClang/blob/master/internals/common.py#L26-L29
• https://github.com/quarnster/SublimeClang/blob/master/errormarkers.py#L4-L7

Is there a reason for this?

Win32 only, an access violation happens during completions.

Currently we have defined some completion symbols such as ".", "->" that trigger completion. This won't work for symbols in the global namespace.

Looks like using throw to throw an exception in a header file causes an error from clang even though the exceptions are enabled with -fcxx-exceptions

If the sublime-clang project file is empty (contains no data) an exception is throw. This doesn't seem reasonable.

There's a bunch of settings that don't need to be user defined settings or are either broken or just hard to understand.

Need to:

1. check which ones are needed
2. test that the settings work as intended
3. fix if needed

To decrease installation hassle, automate the building of libclang.so from source. Look for example how's its done in the original repository using CMake.

Maybe search cache needs some management in terms of size?

in Cursor.from_result the _tu property is not set and the code then asserts. Smells like a bug in some native code. It seems that this method is also called by libclang.so

Check and fix the unit tests and make sure that code completion/parsing works as intended.

This might require some refactoring of the python code to remove connections to sublime modules in order to make it more independent and testable.

I have a feeling that the compiler frontend options will need to change when the language changes to C. This will need verification and fixing. Possibly split options into "cpp_options" and "c_options".

I see calls to bencode/sdecode, not sure what's the purpose of this. Anyway looks like something we can improve on.