my question is very simple, how do I make all warnings become errors on SwiftLint? (without manually configuring each rule separately)
To integrate SwiftLint to your project, you normally need to add a Run Script Phase, as described by the doc.
If you used the CocoaPods installation, this script would look like:
"${PODS_ROOT}/SwiftLint/swiftlint"
That is where you can customize the command line options. In your case, you may want to use:
"${PODS_ROOT}/SwiftLint/swiftlint" lint --strict
The warnings will still be displayed as warnings, but an extra error will be given, preventing running or archiving:
Command /bin/sh failed with exit code 3
That is the desired error.
One drawback with "--strict" flag is that it won't show which line has a Warning.
You can pipe the output and replace "warning" with "error" by adding:
| sed "s/warning:/error:/"
the whole command will look like:
"${PODS_ROOT}/SwiftLint/swiftlint" lint --strict | sed "s/warning:/error:/"
then Xcode will show all SwiftLint warnings as errors.
You can make every swiftlint rule throw an error by enabling --strict
swiftlint lint --strict
Alternatively, you can configure each rule of swiftlint if you are using a config.yml file so that only certain rules throw an error.
swiftlint lint --config 'config.yml'
In the config.yml file simply add the configuration for the rule you want to throw as an error.
implicit_return:
severity: error
I believe this will work for any swiftlint rule. This is useful if you are looking to gradually adopt a stricter approach to linting.
Related
I am building a C++ project using clang-tidy as linter (cmake -DCMAKE_CXX_CLANG_TIDY=clang-tidy).
After updating my system (Fedora 28->29, cmake 3.11->3.12 I believe), I cannot build any more when clang-tidy reports some clang-diagnostic-error (which I cannot fix right now...). I am pretty sure that clang-diagnostic-error's did not interrupt the build earlier... But I cannot be hundred percent sure.
Edit: The change happened in clang-tidy, now it returns a non-zero exit code when errors are found.
Is it possible to suppress those errors, something like the opposite of "-warnings-as-errors"?
Not sure if a solution or a workaround, but this does the trick (in my OS...):
cmake -DCMAKE_CXX_CLANG_TIDY="${PATH_TO_SCRIPT}/suppress_exit_status.sh;clang-tidy"
PATH_TO_SCRIPT to script is the absolute path to suppress_exit_status.sh, which looks like:
#!/bin/sh
$#||echo Command \"$#\" failed with exit code $?
|| is the "or" operator, the second operands is only executed if the first one fails. It seems that cmake captures standard error from the command and throws it way, hence the error message.
I could not figure out a more elegant way to do this, it is not possible to throw || directly into CMAKE_CXX_CLANG_TIDY.
How can I increase the verbosity of the build process?
Bazel seems to print compiler commands only if something goes wrong during the build.
I would like to see which compiler comands the cc_library rule fires, even if everything seems to be fine, to debug linking problems.
I already tried various bazel command line parameters but nothing gives me the compiler commands :(
This is probably what you are looking for:
bazel build --subcommands //my:target
The --subcommands option causes Bazel's execution phase to print the full command line for each command prior to executing it.
Useful information taken from Envoy's bazel readme (https://github.com/envoyproxy/envoy/blob/master/bazel/README.md)
When trying to understand what Bazel is doing, the -s and --explain options are useful. To have Bazel provide verbose output on which commands it is executing:
bazel build -s //source/...
To have Bazel emit to a text file the rationale for rebuilding a target:
bazel build --explain=file.txt //source/...
To get more verbose explanations:
bazel build --explain=file.txt --verbose_explanations //source/...
Maybe you can generate the compile_commands.json file. I have created Shell scripts (under Linux) to automate that: https://github.com/vincent-picaud/Bazel_and_CompileCommands.
You might also find the following useful in addition to the accepted answer of using --subcommands (-s):
bazel build --subcommands --verbose_failures //my:target
The --verbose_failures option causes Bazel's execution phase to print the full command line for commands that failed.
Although it would seem the --subcommands option supercedes it given it is documented to display prior to command execution, I have found cases (with bazel 5.2.0) where for a failing command, --subcommands alone shows only a portion of the command along with <remaining N arguments skipped>. Using both --subcommands and --verbose_failures displays the full command line in these cases.
I'm not sure whether or not this question has a causality with my previous question.
So, I compiled Qt 5.3.1 from source with MinGW 4.8.2. The build stopped at qtbase/src/printsupport directory, as you can see the image below:
Is it a bug or something at qtbase/src/printsupport/kernel/qprintengine_win.cpp file? Then, should I just report it to the developer?
Look here it give you a hint. Probably somewhere you use this key -Werror in make files implicitly or explicitly when start compilation with gcc. If I correct understand error in that switch operation must be default: statement or case PPK_CustomBase: statement.
miraiE,
If you will notice in your output: cc1plus.exe: all warnings being treated as errors
This is, as was mentioned before, a warning that is stopping the compile process as an error.
You should be able to run you configure.bat script again, with the option -no-warnings-are-errors.
Then re-run your make.exe to get past this, and other warnings, from stopping the build.
Details of the specific configure options below:
../qtbase-opensource-src-5.3.1/configure --help |grep -i warn
-silent ............ Reduce the build output so that warnings and errors
-no-warnings-are-errors Make warnings be treated normally
-warnings-are-errors Make warnings be treated as errors
I hope this helps!
we're using xcodebuild for some Jenkins CI tasks.
We have an error that stops the build, but can't see what it is because xcodebuild limits the log length to the first 200 notices:
Showing first 200 notices only
** TEST FAILED **
Is there a way to remove the 200 notice limit? We know we can do this in Xcode using the UI, but need to be able to do it from the command line with xcodebuild
Just use xcodebuild cli.
In Jenkins set "invoke script" step with following content:
xcodebuild clean test -project SOMEPROJECT.xcodeproj -scheme SOMECHEME -destination 'name=iPhone 6,OS=9.1'
You can basically do this in one of the following ways:
a. Add this in your configuration files. OTHER_CFLAGS (Other C Flags)
e.g. OTHER_CFLAGS=-ferror-limit=0
b. GCC_PREPROCESSOR_DEFINITIONS (Preprocessor Macros)
c. INFOPLIST_PREPROCESSOR_DEFINITIONS (Info.plist Preprocessor Definitions)
If in Xcode you want to try, Select Show the issue navigator in left side pane ,select the target, if you have any linker warning or Dsymutil Warning , click anyone of that, you should be able to see the list of all the warning, filter it with by selecting "ALL" and "ALL Issues" in right side pane. You will now be able to see total warnings with details.
I recently discovered the Failures into Break-Points - option from googletest using the command line option gtest_break_on_failure or by defining the GTEST_BREAK_ON_FAILURE environment variable.
I gave it a try using gtest_break_on_failure. From command line, I saw no effect (to be honest I had the glimpse of hope that VS2010 would be registered as debugger and somehow magically would pop up and point to the error source).
Using it in the VS environment as command line argument a failed assertion triggered a break but the call stack did not include the test method that caused the failure. I found the work around to step (F10) until I reached my test code, but that does not really seem to be convenient.
Is it somehow possible to use the option from command line ?
Has anybody a recommendation how to get the correct call stack in the environment?
From VS, you can add --gtest_break_on_failure to the Command Args in the target's Property Pages, then just run the exe without stepping over.
From the command line, you should be able to run the Debug executable with the flags --gtest_break_on_failure --gtest_catch_exceptions=0 and this should allow you to break into the MSVC debugger when the test fails.