A recent change to run-clang-tidy.py means that the underlying clang-tidy command is now always run with -use-color. The question is how to disable that.
I use this script with the Sonarqube Community C++ plugin and this cannot handle the extra colourisation characters - FTR it reports that all the files cannot be found in the associated repo.
I have tried adding extra parameter -config '{"UseColor":false}' but it made no difference.
Short term, I will probably locally modify the python script. Long term, I wonder if there is a better approach?
This issue is now fixed in LLVM's main branch and should be resolved in the next release. The old default behavior has been restored and you'll be able to explicitly opt in or out of colored output using the -use-color option.
As a short-term fix, you can strip out the ANSI escape characters that enable colored output yourself. See Removing colors from output for instructions.
Related
I am trying to wire up various yeoman generators as External Tools in JetBrains WebStorm (as well as JetBrains Rider) and am experiencing a very peculiar problem with the output.
On generators that take any kind of input, there is all sorts of cattywompus output, specifically duplicated output that is obtusely fragmented.
Thinking this might be a problem with the terminal encoding, I've turned the encoding to UTF-8 in the *.vmoptions file as told by support by adding -Dfile.encoding=UTF-8 to the file and rebooting.
But it doesn't seem to matter what I do, or how I configure it - when I configure a yeoman generator as an external tool, I get obscure output. I've captured the phenomenon in a screen cast here;
VIDEO OF THE PROBLEM OCCURRING
I have also just included a screenshot, for those who would rather not watch the video.
These are the settings I'm using for the external tools, in their respective order;
For good measure, here is a repository of the exact generator I am using in the video and screenshots; The easiest way to make this available is to run
npm install
npm link
The problem is caused by ANSI sequences processing in external tools console. Yo generator uses inquirer.js module that, in turn, uses some special ANSI escape sequences to format the output, namely
CSI 8D Cursor Back
CSI 8C Cursor Forward
CSI 2K clear entire line
these sequences are not currently supported; please follow IDEA-149959 and linked tickets for updates
I only noticed this because of the project I was working on with a client's CSS file. I was using Compare in 1.13 to check existing CSS information with some changes I was doing for her. When I upgraded to 1.14, the Compare function was wonky, allowing me to tag one file for Compare and then not allowing the right-click on the second (or any other) file. This lead me to believe it was removed, but I didn't see any mention of it in the release notes.
I've since gone back to 1.13. I rarely use Compare, but in this one instance it alerted me that there may be other issues of which I'm unaware, especially if right-clicking file names in the File Explorer doesn't respond.
The Compare feature was untouched in 1.14, this does not mean, however, that the feature isn't subject to any current bugs related to your platform. On Mac OS X the feature is working as intended.
But as a long time user I've found that the Compare feature has been unintuitive.
I would suggest either using the Diff feature (F7 or Shift+F7) or perhaps switching to using git and it's diff-ing tool.
I work with a medium sized team of developers, with half being Linux developers using VIM on Ubuntu and MacVIM on OSX, and the other half being Windows developers using Visual Studio 2010 or later.
A fair bit of time has been wasted in the past when handling things like SVN operations failing due to mixed line endings, or changes to code reviews due to a mix of hard-tabs versus spaces-as-tabs (and sometimes of varying lengths, ie: 4 spaces vs 2 spaces vs 8 spaces, etc), and I would like to put an end to it.
The plan is to adapt a common coding style we've designed, which is almost identical to the Linux Kernel coding style. For all developers, we could require them to run their code through the checkpatch.pl script used by Linux kernel devs, but our code includes C, C++, and C#, so we would need to generalize the rule checker script beyond just ANSI C.
Is there a generic way to implement a rule set for VIM, and another for Visual studio? We'd like to generate a script that checks entire files, which could be hooked into our version control system so that it's run on code before commits complete, and perhaps as a run-time script to enforce the style as coders type?
Thank you.
EditorConfig seems to do exactly what you want in Vim, Visual Studio, and a lot of other editors and IDEs.
The run-time "script" is the best first-line of defense. In this case, it will be various Vim and Visual Studio settings to help enforce your code style. That alone will catch quite a few problems. Keep in mind, this won't catch everything, but will encourage the coding style you want.
I've worked across Linux & Visual Studio in a team before (and sometimes by myself). The whole Tabs/Spaces issue drove me nuts as there would be wholesale groups of lines that were either shifted WAY over or not enough. To solve this, I ended up using these three settings in Vim (also set similar values in Visual Studio), thus catching one class of issues at the root.
Vim
set expandtab
set shiftwidth=4 " Mainly for if/for/while/general {} block indentation. 4 spaces.
set softtabstop=-1 " Allows us to use the Tab key and have it act like shiftwidth.
Visual Studio
Insert spaces when Tab key is pressed.
Shift 4 spaces on indent inside code block
They key is getting rid of the Tab characters, or at least having both systems use the SAME SETTINGS (i.e. both using Tab with the same values or SPACEs substituting as Tabs)
Something to watch out for:
Someone copying a file from one Operating System to a different one and then checking the file into SVN on that machine. SVN will blindly commit, say, a DOS line-ending file from a UNIX system. You want to checkout/commit files on the same system only. Otherwise, checking out/editing/committing files all on the same OS should present no issues, as SVN can convert the line endings upon checkout. You can "fix" this by loading a file into Vim and then converting the line-endings to the particular OS you want by typing ":set fileformat=dos" (if you want to change to Windows-style), ":set fileformat=unix" (for unix style), or finally ":set fileformat=mac" for Mac.
As far as the code style goes, as you probably already know, both Vim and Visual Studio offer lots of flexibility there. While I cannot give you the specific settings for Vim, the options to look at are
autoindent
cindent
cinoptions (implied from cindent)
cinkeys (implied from cindent)
comments (default is probably fine, but here for thoroughness)
So, you will want
set autoindent
and cindent should be automatically set when editing a C or C++ file. The defaults for cinoptions and cinkeys are ok for me, but I have tweaked them in the past when working with a different group.
Don't forget about using the '=' command over a selected range of lines to reformat the code! This can be very handy!
I shy away from the completely automatic SVN backend method because it may take longer than you expect to get it right, and when it screws up, it will probably take more time out of your day than you expect as well. After all, you really just want to be productive, right?.
Discipline up front is key!
I am using PC-Lint for my C++ project.
Is there a way to switch off all error and warning messages by default, so I can then reintroduce the required messages explicitly?
I have read the chapter of the PC-Lint manual entitled "Error Inhibition Options" and the best I could find was setting the wLevel to -w0 No messages (except for fatal errors)
Yes, it is possible, you can simply use -e* or -w0. However, the manual truly states (Chapter 16. Living with Lint):
DO NOT simply suppress all warnings with something
like: -e* or -w0 as this can disguise hard errors and make subsequent diagnosis very difficult.
So, yes, you can use it if your code is basically cleaned, and you want to review recent changes for a certain set of messages. But if you want to start cleaning your code, and are swamped with messages because of the default warning level -w3, I suggest to start using -w1, and resolve all issues there; most of the warnings/errors given at level one indicate problems with finding all header files, having al implicit macros set properly, and/or mimicking the compiler you use normally in a sufficiently precise way.
As always, I hesitate to advertise my own work, but if you want, take a look at my "How to wield PC Lint" PDF, where I have documented detailed instructions to handle the initial deployment of PC Lint and tackling the many warnings/errors/infos/notes you may be buried under.
When I started introducing PC-Lint to a new project I did the following:
As suggested by Johan Bezem, ran a -w1 level check over the whole thing. This doesn't actually find any new problems, but checks that your program is syntactically valid and finds any configuration issues. Nothing major, assuming your project compiles already.
Run the test again with -w2 level. This found 53,000 issues, which was a bit much to tackle in one go.
Pick a typical bad file, then suppress any errors that seem
irrelevant or non-urgent (eg. error 525: (Warning -- Negative indentation from line xxx)
adding -e525 to the command line or config file, until you find one that seems serious.
In my case this was
error 442: (Warning -- for clause irregularity: testing direction inconsistent with increment direction), i.e. a 'for' loop
that looked like it should be counting up was actually counting
down.
Reset the test level back to -w1 but added in the critical problem by number, -w1 +e442 in this case. Re-run it over the whole project then fix all the instances of that problem.
Back to stage 2 and try again.
This combination of fixing actual problems and suppressing likely false alarms soon gets your numbers under control.
So that everything gets better over time we also implement a script that does a thorough (full -w2 or -w3) check on any files that are created or modified.
I also found the tool LintProject very helpful as it can do an entire Visual Studio solution in one go, with tables with numbers of errors and worst offenders!
I am trying to insert a custom preprocessor into the VC++ 2010 build-pipe after the regular preprocessor has finished, so far i figured that the way of doing this is via MSBuild.
To this point I wasn't able to find out much more, so my questions are:
Is this possible at all?
If so, what do I need to look at, to get going.
If you are talking about the c/c++ preprocessor, then you are probably out of luck. AFAIK, the preprocessor is built into the compiler itself. You can get the compiler to output a pre-processed file and then you MIGHT be able to send that through the compiler a second time to get the final output.
This may not work anyway due to the code being produced, at least in previous versions of cl.exe, doesn't seem to be 100% correct (white space gets mangled slightly which can cause errors).
If you want to take this path, what you'd need to do is have an MSBuild 'Target' that runs before the 'ClCompile' target.
This new target would have to run the 'cl.exe' program with all the settings that 'ClCompile' usually sends it with as well as the '/P' option which will "preprocess to a file".
Then you need to run your tool over the processed file and then finally feed these new files into 'ClCompile'.
If you need any more info just reply in the comments and I'll try to add some when I get the time (this question is rather old, so i'm not sure if it's worthwhile investing more time into this answer).