search

Sarcasm / irony-mode

A C/C++ minor mode for Emacs powered by libclang
GNU General Public License v3.0
901 stars 98 forks source link

irony no longer outputs clang compiler warning errors with debug mode #395

Open 3246251196 opened 7 years ago

3246251196 commented 7 years ago 
    (setq process
          (start-process-shell-command
           "Irony"                    ;process name
           irony--server-buffer       ;buffer
           (format "%s -d -i 2> %s"      ;command

irony*.log does not include any information.

Sarcasm commented 7 years ago

Indeed. And I added a set-debug command that is not bound.

Debug is added on a per-need basis. Any issue you have in particular?

3246251196 commented 7 years ago

So when emacs starts the irony-server we must run set-debug once before incoming completions as opposed to just instantiating the server with the -d flag (which you can still do, but its behaviour is different).

Am I right in interpreting your previous reply as.. you have forgot to add something to the lisp end such that the user can set debugging (which, from here on out, I will call clang-debugging, since this is really what I mean).

I am just not so sure I prefer the new way.

The problem is that boost headers are still a problem with speeds. Sometimes I point the .clang_complete to a fake set of boost headers that are all truncated. Therefore, clang does not know what these boost structures are in the codebase. However, I still get completions, so this is fine and this is quicker. But, certain translation units refuse to complete - albeit this seldom happens - (or give unexpected completions) due to including fake boost. I can hack my way around this by looking at clang-debugging and typedefining some unknown boost structure so I can shut the clang compiler up. Yes, this is utterly horrible.

Alternatively, I can give point .clang_complete to the proper boost location. This means a longer start up time but proper completions.

I am in a constant trade off between fake-boost and proper boost.

Further to this, I have started to enable the clangpreamble option and this is great. Subsequent completions are almost instantaneous whether I use fake boost or not. However, I am noticing that I can be in a translation unit: first completions takes a while, subsequent ones are "instant". Then I can go somewhere else or do something else in emacs and then go back to the translation unit and all of a sudden subsequent completions take a number of seconds (but, not so long as the original parse). Next time this happens I will debug into irony-server and find out what is taking a while: it will likely be one of the clang APIs; why it slows down all of a sudden I do not know; it is like something is constantly invalidating something in the TU.

  1. Regardless, I find it very useful to look at clang-debugging information in *.log. I can hack this in for now, but I am wondering how to enable it as you intended and it looks like I need to be in an interactive session and supply set-debugging before completion actions.

  2. I wonder if irony-server should kill itself and start a new server on every translation unit, though I question: what defines a TU? What should be done for headers etc?

  3. I wonder if I could implement something where irony server kills itself and reparses the current buffer after some idle time.

  4. I may use my function which parses buffers on start-up. I know this is done by flycheck but I do not use it.

These are never issues for code-bases that are fairly small. But when you are using a big code base AND boost, these things show themselves. I just wanted to through a few points out there and I may hack around myself.

Cheers.

Sarcasm commented 7 years ago

So when emacs starts the irony-server we must run set-debug once before incoming completions as opposed to just instantiating the server with the -d flag (which you can still do, but its behaviour is different).

Am I right in interpreting your previous reply as.. you have forgot to add something to the lisp end such that the user can set debugging (which, from here on out, I will call clang-debugging, since this is really what I mean).

I am just not so sure I prefer the new way.

What would be possible, if the Elisp part was to be completed is to create a function irony-toggle-debug for example. Which can enable debugging if irony-server is already running, and which will start irony-server with the -d flag if it is not started yet.

Anyway, the -d works the same as the command, it's just that it happens on startup.

  1. Regardless, I find it very useful to look at clang-debugging information in *.log. I can hack this in for now, but I am wondering how to enable it as you intended and it looks like I need to be in an interactive session and supply set-debugging before completion actions.

-d should still work great.

  1. I wonder if irony-server should kill itself and start a new server on every translation unit, thought I question: what defines a TU? What should be done for headers etc?

Headers aren't treated any different from source file, so you could say one TU per file I think.

  1. I wonder if I could implement something where irony server kills itself and reparses the current buffer after some idle time.

It should not be too difficult, emacs has idle timers and you can restart irony-server, you just have to find the right combination for your use case.

  1. I may use my function which parses buffers on start-up. I know this is done by flycheck but I do not use it.

Yeah, this should be "trivial", you have to make a function that sends a parse request as an irony-mode-hook. Not tested and not pretty but for example:

(add-hook 'irony-mode-hook 'irony-get-type)

These are never issues for code-bases that are fairly small. But when you are using a big code base AND boost, these things show themselves. I just wanted to through a few points out there and I may hack around myself.

Yeah, I agree about the limitations, for example, I can easily see irony-server take too much memory on my system, it happens because the TU are never released, this is not nice but usually it is ok for the codebase I work on because I restart Emacs from time to time.

If you don't use flycheck, but you are still interested in the diagnostics, you don't need the log file, you can just do something like this:

M-: (message "%S" (irony--run-task-synchronously (irony--diagnostics-task))) RET

3246251196 commented 7 years ago

@Sarcasm

-d is not working as it used to for me. I now do not get clang-debugging. See the first post to see what I have done which used to work pre-io.

Sarcasm commented 7 years ago

Is the file really empty? It does not contains the Execute lines at all?

3246251196 commented 7 years ago

The file contains the execute commands etc.

3246251196 commented 7 years ago

Are we mixed up here? I get irony-debugging - if that's what you mean. I was under the impression that I need to turn on clang-debugging using this set-debug - which is at default for now?

Sarcasm commented 7 years ago

I don't understand.

To resume:

What "debug" information are you actually missing? One that was here before? For example the diagnostics? If that is so, I proposed a solution to get these diagnostics without debug, c.f. the very very end of the comment: https://github.com/Sarcasm/irony-mode/issues/395#issuecomment-308576338 Or do you want to have some new, custom, debug in the log file?

3246251196 commented 7 years ago

Okay, that will be it then; that you have removed verbose logs. That is what I find very useful. I will just have to look into this/use end of #395.

3246251196 commented 6 years ago

@Sarcasm Hello Sarcasm. I am coming back to this ticket because I find that it really is a burning issue for me: not having the compiler output of clang in the log file.

Can I just confirm that this has now disappeared with the new version. If so, I really think there should be an option to reinstate it.

3246251196 commented 6 years ago

@Sarcasm Okay, this was actually very easy to put pack since it was trivial to put the old section of Irony.cpp (an old version) into the new iotask version, I now get diagnostics. Should I work on allowing this for the current version or do you still not want this?

Sarcasm commented 6 years ago

You can make a PR to add the diagnostics in debug mode, no problem. :+1: