8000 deal with compiler parameters that have spaces in them · Issue #178 · Sarcasm/irony-mode · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

deal with compiler parameters that have spaces in them #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nickbroon opened this issue Feb 24, 2015 · 6 comments
Open

deal with compiler parameters that have spaces in them #178

nickbroon opened this issue Feb 24, 2015 · 6 comments

Comments

@nickbroon
Copy link

Can you provide some documentation on how to debug irony mode, irony-server, etc?

Looking at /tmp/irony.*.log the only error I see an error like this:

error: libclang couldn't parse '/home/user/project/src/file.c'
execute: Command{action=Command::Complete, file='......

This is after adding -d to the call to irony-server in irony.el
The file and long list of flags, presumably passed from irony-cdb looks about right for my project.

How do I call irony-server manually from a shell specifying both the file and the flags, etc, so that I can debug further

@Sarcasm
Copy link
Owner
Sarcasm commented Feb 24, 2015

Hi,

You can do the following to see if the error happens when running irony-server manually:

$ ~/.emacs.d/irony/bin/irony-server -d -i
parse /home/user/project/src/file.c
<compile options on this line...>
diagnostics # only if parse worked, output 't' and not 'nil'

If parsing failed, you should try the same command with clang (the same version as your libclang, ldd ~/.emacs.d/irony/bin/irony-server):

clang++ <compile options...> /home/user/project/src/file.c

@nickbroon
Copy link
Author

I think that I might be being affected by rizsotto/Bear#77
During manually using irony I was seeing:
libclang: crash detected during parsing: {
and when running clang directly I got the above reported quoting error.

@nickbroon
Copy link
Author

So it appears rizsotto/Bear#77 is not the problem.

The compile_commands.json contains the following:

    {
        "command": "gcc -DPACKAGE_NAME=\"company-functionality\" -DPACKAGE_TARNAME=\"company-functionality\" -DPACKAGE_VERSION=\"2.4\" -DPACKAGE_STRING=\"company-functionality 2.4\" -DPACKAGE_BUGREPORT=\"company-support@company.com\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_MEMSET=1 -DHAVE_STRDUP=1 -DHAVE_STRTOL=1 -DPACKAGE=\"company-functionality\" -DVERSION=\"2.4\" -I. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -Werror -Wall -fPIC -I ../include -I ../lib/inih -I ../ -DVERSION=\"2.4\" -DPROG=\"company-functionality\" -g -O2 -MT functionality.o -MD -MP -MF .deps/functionality.Tpo -c -o functionality.o functionality.c",
        "directory": "/home/user/Work/company-functionality/src",
        "file": "/home/user/Work/company-functionality/src/functionality.c"
    }

irony executes the following:

error: libclang couldn't parse '/home/user/Work/company-functionality/src/functionality.c'
execute: Command{action=Command::Complete, file='/home/user/Work/company-functionality/src/functionality.c', line=114, column=12, flags=['-x', 'c', '-working-directory', '/home/user/Work/company-functionality/src', '-DPACKAGE_NAME=company-functionality', '-DPACKAGE_TARNAME=company-functionality', '-DPACKAGE_VERSION=2.4', '-DPACKAGE_STRING=company-functionality', '2.4', '-DPACKAGE_BUGREPORT=company-support@company.com', '-DPACKAGE_URL=', '-DSTDC_HEADERS=1', '-DHAVE_SYS_TYPES_H=1', '-DHAVE_SYS_STAT_H=1', '-DHAVE_STDLIB_H=1', '-DHAVE_STRING_H=1', '-DHAVE_MEMORY_H=1', '-DHAVE_STRINGS_H=1', '-DHAVE_INTTYPES_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_UNISTD_H=1', '-DHAVE_ARPA_INET_H=1', '-DHAVE_NETINET_IN_H=1', '-DHAVE_STDDEF_H=1', '-DHAVE_STDINT_H=1', '-DHAVE_STDLIB_H=1', '-DHAVE_STRING_H=1', '-DHAVE_SYS_SOCKET_H=1', '-DHAVE_UNISTD_H=1', '-DHAVE__BOOL=1', '-DHAVE_STDLIB_H=1', '-DHAVE_MALLOC=1', '-DHAVE_STDLIB_H=1', '-DHAVE_REALLOC=1', '-DHAVE_MEMSET=1', '-DHAVE_STRDUP=1', '-DHAVE_STRTOL=1', '-DPACKAGE=company-functionality', '-DVERSION=2.4', '-I.', '-I/usr/include/json-c', '-I/usr/include/glib-2.0', '-I/usr/lib/x86_64-linux-gnu/glib-2.0/include', '-g', '-Werror', '-Wall', '-fPIC', '-I', '../include', '-I', '../lib/inih', '-I', '../', '-DVERSION=2.4', '-DPROG=company-functionality', '-g', '-O2', '-MT', 'functionality.o', '-MD', '-MP', '-MF', '.deps/functionality.Tpo'], unsavedFiles.count=1, opt=off}

So the obvious difference is the missing -c -o functionality.o but I'm guessing that is intentional?

But I wonder if irony is quoting/escaping the strings properly? Specifically the DPACKAGE_STRING=company-functionality', '2.4' bit looks wrong. When I run the command manually I have to make sure to quote this part, and then clang happily parse/compiles the file.

clang -x c -working-directory /home/user/Work/company-functionality/src -DPACKAGE_NAME=company-functionality -DPACKAGE_TARNAME=company-functionality -DPACKAGE_VERSION=2.4 -DPACKAGE_STRING="company-functionality 2.4" -DPACKAGE_BUGREPORT=company-support@company.com -DPACKAGE_URL= -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_MEMSET=1 -DHAVE_STRDUP=1 -DHAVE_STRTOL=1 -DPACKAGE=company-functionality -DVERSION=2.4 -I. -I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -Werror -Wall -fPIC -I ../include -I ../lib/inih -I ../ -DVERSION=2.4 -DPROG=company-functionality -g -O2 -MT functionality.o -MD -MP -MF .deps/functionality.Tpo -c -o functionality.o /home/user/Work/company-functionality/src/functionality.c

@Sarcasm
Copy link
Owner
Sarcasm commented Feb 25, 2015

So the obvious difference is the missing -c -o functionality.o but I'm guessing that is intentional?

That is intentional.

I think irony may have to prune the -MD -MP -MF .deps/functionality.Tpo flags as well.

But I wonder if irony is quoting/escaping the strings properly? Specifically the DPACKAGE_STRING=company-functionality', '2.4' bit looks wrong. When I run the command manually I have to make sure to quote this part, and then clang happily parse/compiles the file.

You are right, this one doesn't look right. I already have some tests with quotes handling,

(ert-deftest irony/split-command-line/with-quotes ()
, I will add a test for your example and see.

@Sarcasm
Copy link
Owner
Sarcasm commented Feb 25, 2015

Well I guess it is kind of a known issue:

(defun irony--split-command-line (cmd-line)

@nickbroon
Copy link
Author

Fantastic, at least we've root caused the problem. We can use this issue to track fixing the TODO in the code.

@nickbroon nickbroon changed the title Debugging help deal with compiler parameters that have spaces in them Feb 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0