After 4.4.0, Sphinx introduce a function for checking if hardcoded URLs can be replaced with extlinks, I got a lot of warning when build my documentation.
I don't want to replace my links to extlink's role. How can I suppress them?
Related
Is there a way to sort my #include statements in Clion? Additionally, can I do this automatically every time I save? I didn't manage to find any such functionality or plugin.
Yes, it is possible with help of clang-format.
File->Settings...->Languages & Framework->C/C++->Clangd->Enable clangs server
clang-format should be installed in your system. Normally it is available in your favourite repository. You can specify the path to it if required
File->Settings...->Tools->clang-format
You have to put .clang-format file into your project root with coding rules. More information you can find on clang-format web site. For example, I am using Google coding rules. My content looks like this:
Language: Cpp
BasedOnStyle: Google
This includes already the include statements sorting. However, there is a choice of other ready-to-use coding styles like LLVM, Mozilla, WebKit, Chromium which you can use and if necessary modify or you can create your own format by providing set of rules you want. The rule you might be interesting in is
SortIncludes (bool)
If true, clang-format will sort #includes.
Please refer to the clang format documentation here
How do I suppress a CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF warning on a per file basis in Xcode?
I would like to to suppress some warnings using the per-file option Compile Sources in Xcode.
I've tried:
-Wno-CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF
-fno-CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF
I've usually done this kind of suppression with a pragma directive.
(PS I don't need to be told that this isn't a good thing to be doing.)
OK, for the benefit of others, it's -Wno-implicit-retain-self
I should have realised this. The corresponding flag should have been used,, which I found here
Is there a way to enforce gcc to ignore errors which result from C++11's override?
Explanation: I want to enable C++11 in a program. Unfortunately it misused some functions and macros from a library causing many marked override, but does not override errors. So I want to disable the error, just to check if there are more issues and then replace the errors step by step.
I checked the -W options, but they handle warings only. This is a real error.
As a hack you can use -Doverride= on the command line. This will make it so GCC does not see override.
Using PC-Lint, I'm attempting to make a header file be treated as a library header so that I can suppress messages from inside it. I'm using the library module option +libm(module.c) which should treat module.c as a library module and any headers it includes (i.e module.h) as library headers as described in section 6.1 of the PC-Lint manual for v9.00. Naturally, module.h is also included in my source files which are not library modules.
The problem is that when I lint the code, I still get messages from module.h even though I provided the +libm(module.c) option. I suspect this is because the module.h file is included in my other non-library modules. But such a situation is a typical use case and so this makes this +libm option useless. I know I could use +libh(module.h) or +libdir(...) but I want +libm(module.c) to work properly for me. Any suggestions?
It is not presented like that in the manual, but my experience shows that not all header files included by the library module are considered library. They cannot be: What if the module includes your own header files, the header files you want explicitly to be processed?
Use the Lint option -vf (caution: large output!) to see how Lint interprets your header files. Library files are designated as such.
The ones missing can be added using the normal -lib* option set.
We like the Warnings as Errors setting as we have a policy of not checking in code with warnings and this is the only effective way we have found to enforce it.
We also like to use the Obsolete attribute to flag methods that should not be used any more.
Problem is that adding a Obsolete attribute to a method or class immediately causes tons of projects to not build (not to mention problems if a .NET API call is deprecated).
Does anyone have a good solution to this?
We want a visible, hard-to-ignore indicator that you are using a deprecated API but that does not cause the build to fail. We want to see the warnings in the IDE and in CI builds.
A simple solution would be to have a build configuration (e.g. your debug build configuration) without warnings as errors. If, however, the point is to flag to your developers that something is wrong on build, that's no good as they'll forget to do a release build before they check in.
Alternately, rather than using "warnings as errors" you could set up your ruleset to throw errors itself rather than raise warnings. This will mean, of course, that non-CA warnings won't cause errors.
The best solution, I think, would be to handle it on the server side. Ideally you'd have some sort of gated checkin so that your code repository rejects commits that don't build using its build definition (with warnings-as-errors on, and your developers can leave warnings-as-errors off). I suspect that's a TFS-2k10-only feature though.
This other stack overflow post should help:
https://stackoverflow.com/a/468166/9195608
Basically it says:
You can add a WarningsNotAsErrors-tag in the project file.
<PropertyGroup>
...
...
<WarningsNotAsErrors>612,618</WarningsNotAsErrors>
</PropertyGroup>
Note: 612 and 618 are both warnings about Obsolete
The difference between 612 and 618 is the comment of the ObsoleteAttribute. An ObsoleteAttribute without comment generates the error 612, and one with a comment generates 618.
As explained here /sdl (Enable Additional Security Checks), if you switch off SDL the compiler will treat it as a warning.