niosus / EasyClangComplete

:boom: Robust C/C++ code completion for Sublime Text 3/4
https://niosus.github.io/EasyClangComplete/
MIT License
575 stars 78 forks source link

Not working on apple m1 arch64 #752

Closed dortamiguel closed 2 years ago

dortamiguel commented 3 years ago

System info:

What happens:

The plugin doesn't works on apple m1 machines. The same CMakeLists.txt I have compiles fine on an x86_64 machine

Here is the small version of the log

[ECC:INFO   ]: Getting version from command: `clang++ -v`
[ECC:WARNING]: OSX version 12.0 reported. Reducing it to 7.0.
[ECC:INFO   ]: Found clang version 7.0
[ECC:INFO   ]: init completer based on libclang
[ECC:INFO   ]: Found libclang library file: '/Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/../../libclang.dylib'
[ECC:ERROR  ]: error while compiling: Error parsing translation unit.
[ECC:CRITICAL]:  cannot create translation unit. Abort.
[ECC:INFO   ]: init completer based on libclang
[ECC:ERROR  ]: error while compiling: Error parsing translation unit.
[ECC:CRITICAL]:  cannot create translation unit. Abort.

And here is attached the full log log.txt

I also attached my CMakeLists.txt just in case it can help CMakeLists.txt

How I can fix this?

dortamiguel commented 3 years ago

I'm trying to help fix this, so far I found that the error happens here

https://github.com/niosus/EasyClangComplete/blob/master/plugin/completion/lib_complete.py#L149

which is calling clang_parseTranslationUnit from the cindex50.py plugin

https://github.com/niosus/EasyClangComplete/blob/master/plugin/clang/cindex50.py#L2715

seems like clang_parseTranslationUnit just silently fails and returns null, do you know a better way of debugging this issue?

niosus commented 3 years ago

@ellipticaldoor while I don't own any M1 macs unfortunately, I did try the plugin on a friends' mac some time ago and it seemed to work as I expected. So I would assume there is something else fishy here. Looking through your log, I see some lines that trigger my attention:

[ECC:DEBUG]:[flag.py]:[tokenize_list]:[Thread-4]: Tokenizing: ['/usr/bin/clang++', '-I/Users/miguel/src/prototype/include', '-O3', '-DNDEBUG', '-arch', 'arm64', '-isysroot', '/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk', '-O2', '-Wall', '-Wextra', '-Wno-error=unused', '-Wno-error=unused-parameter', '-Wpedantic', '-Wdouble-promotion', '-Woverloaded-virtual', '-Wnull-dereference', '-Wformat=2', '-Wundef', '-Wconversion', '-Wfatal-errors', '-Wshadow', '-Wmissing-noreturn', '-Wunreachable-code', '-Wno-c99-extensions', '-Wno-gnu-zero-variadic-macro-arguments', '-Werror=return-type', '-Iinclude', '-fno-common', '-std=gnu++2a', '-o', 'CMakeFiles/prototype.dir/src/main.cpp.o', '-c', '/Users/miguel/src/prototype/src/main.cpp']
[ECC:DEBUG]:[flag.py]:[indicates_flag]:[Thread-4]: '/usr/bin/clang++' doesn't start with any valid flag prefix: ['-']
[ECC:DEBUG]:[flag.py]:[indicates_flag]:[Thread-4]: 'arm64' doesn't start with any valid flag prefix: ['-']

Maybe this is the cause. Can you also tell me your ECC settings?

dortamiguel commented 3 years ago

Ah, I think it might be that now to specify which architecture you want to run you have to first the command arch like this

$ arch -arm64 clang++ -v
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: arm64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ arch -x86_64 clang++ -v 
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

My settings are now this

{
  "verbose" : true
}

So there must be something appending the arch -arm64 and its confusing the tokenize_list, right?

dortamiguel commented 3 years ago

I found a fix!

If the -arch flag is passed to the tokenize_list function then ignore it:

        log.debug("Tokenizing: %s", all_split_line)
        for i, entry in enumerate(all_split_line):
            entry = entry.strip()
            if entry.startswith("-arch"):
                continue
            if entry.startswith("#"):

Here is the original code https://github.com/niosus/EasyClangComplete/blob/master/plugin/utils/flag.py#L110

Probably there is a less hacky solution for this... I hope this points in the right direction for a better fix

I can open a PR with this fix unless you suggest something else, thanks for your help!

niosus commented 3 years ago

Yeah, that looked like it. Thanks for testing this out. I will try to push the solution this weekend.

niosus commented 2 years ago

Ok, so I just ended up adding the arch flag to "separable" flags and could runt the plugin on the M1 Mac. The PR with the change is here #761. Please reopen if the issue persists with the new release that is about to land in the next hour.