I have a large legacy codebase and I want to start working on the warnings. How can I get rubocop to just show me the warnings (lines starting with W:) and worse, and suppress all the convention (lines starting with C:)?
Utilize the --display-only-fail-level-offenses[1] flag and set the fail-level[2] to warning:
rubocop --fail-level warning --display-only-fail-level-offenses
I discovered that rubocop splits the rules into different categories: Syntax, Lint and others:
If you don't have any custom severity levels in your configuration, it's quite simple. The Synax cop reports on fatal and error level, Lint cops on warning level and all other cops on convention level.
So for only fatal and error, it's rubocop --only Syntax (which is only supported on master, not released yet), and for warning and above it's rubocop --only Lint.
Therefore it's the Lint errors that I need to fix first.
In my case the best way to handle this was to work top to bottom through the rubocop_todo.yml which can be created with:
rubocop --auto-gen-config
Since the rubocop_todo.yml file is created in order of severity ie Syntax ones at the top, followed by Lint, followed by others, working through them in order fixes the warnings first.
Related
In our project we use checkstyle as static analyzer (as maven plugin, I mean maven-checkstyle-plugin). I am new to this tool, and there is one thing I want to find out - what is the difference between failOnError and failOnViolation?
I think the plugin documentation is pretty clear, but the minimum expectation is going to be:
Do you want a log of the errors before failing the build? Then use failOnViolation
Or
Do you want to fail the build immediately, without waiting for errors to be logged? Then use failsOnError
Of course, if you set logViolationsToConsole to false (or on the CLI as -Dcheckstyle.console=false), then both act almost identically and can cause some confusion.
I would like to force my cmake based configuration to fail ( and possibly print a message ) if:
there are unused variables ( which are likely to be a typo in most cases )
there are unused modules ( same thing as before or useless stuff )
a particular if is not being evaluated to TRUE
I find that the fact that cmake is macro based solution makes it hard to spot errors on big projects, so if someone has some some hints on that. Basically cmake doesn't alert you because anything could be a custom variable and not necessarily a typo or a mistake.
Let's address your points out-of-order.
a particular if is not being evaluated to TRUE
The way to achieve this is a FATAL_ERROR message:
if(SOME_CONDITION)
message(FATAL_ERROR "You did something wrong!")
endif()
there are unused variables
This is more difficult. There are the --warn-unused-vars and --warn-uninitialized command line options, but this has to be given by the user when running CMake. It is not possible to enforce this behavior from within a CMake script.
Also, there is no way to turn these warnings into fatal errors: CMake will still try to produce a valid Makefile (and may succeed in doing so). The only viable solution here seems to be developer discipline: Whenever a developer makes changes to the build environment, they should be aware of this compile options and check their code accordingly. Just as you would do with your other source code.
If you have trouble enforcing this, try to provide a shell-script as a wrapper that already sets all of the desired command line options. While not perfect, this will at least remove the obstruction of having to look up that damn parameter in the manual for your developers.
there are unused modules
This is not possible, but I also don't see a big problem here. Worst thing that can happen is that pulling in the module adds some noise to the cached variables, but none of that would have any influence on the final generated build files.
CMake modules should always be kept small enough so that pulling them in should have no noticeable impact on the runtime of your CMake configure run.
Before I begin I must admit that I am new to Xtext and the designing of DSLs. Some of my questions on this matter may be somewhat "less than intelligent".
I have created an Xtext project using the IDE, and I am simultaneously using one of the sample projects provided with Xtext as a guide to what I need to do in my language. I am seeing a lot of warnings that are making me nervous.
Apparently, when the development environment creates a new project, it somehow configures that project to use the Java 5 libraries. I am using Java 6, and as a result I get warnings saying that my project is configured for Java 5 and there is no Java 5 on my system (which there isn't!).
I have tried altering the build path so that it uses Java 6 libraries, but this generates a number of other warnings -- including warnings that the Java 6referenced in my manifest.mf file is invalid!
Then there are the "plugin.xml" warnings. Apparently, the build.properties file references a file called "plugin.xml" which is not created when the IDE creates the project. I have no idea whether or not this file is important enough to create, and I have no idea what should go into it.
Frankly, I hate warnings. Warnings tend to lead to future problems in what I produce. I like clean compiles and clean deployments. I would like to eliminate these warnings, before they start screwing me up down the road (like putting in Java6 classes that would break in a Java5 library).
Has anyone been able to eliminate these warnings reliably? Please advise.
For the JDK warning, you simply switch in the Manifest.MF to a target environment matching your preferred JDK ('JavaSE-1.6 ' in your case).
The warning regarding the missing plugin.xml will be gone as soon as you have run the grammar generator the first time, as it will produce such a file.
I have undoubtedly set something up wrong but frequently I get exceptions thrown by my Razor templates even though there is no problem with the templates. These are usually fixed by my doing a build.
If I do actually have an error in the template I get a popup asking me to debug in VS, but of course this does not actually allow me to debug the template.
Errors in my log are not all that helpful (see below).
Is it possible to both avoid spurious errors and get better information when there is actually a problem?
ServiceStack.Razor.Templating.TemplateCompilationException: Unable to compile template. Check the Errors list for details.
at ServiceStack.Razor.Templating.TemplateService.CreateTemplate(String template, Type modelType)
at ServiceStack.Razor.Templating.TemplateService.Compile(ViewPageRef viewPageRef, String template, Type modelType, String name)
at ServiceStack.Razor.Templating.TemplateService.Compile(ViewPageRef viewPageRef, String template, String name)
at ServiceStack.Razor.ViewPageRef.Compile(Boolean force)
I was having similar problems. I found the "easiest" way to find out what the error was, was to download all of service stack, build a debug version of the razor libary and link it into my project. I then set a break point in the ServiceStack.Razor.Templating.TemplateService.CreateTemplate method and was able to see the full exception details. From there I learnt that I had included an import in my razor page that was not referenced in my project.
Since I solved this it's been very reliable.
I had trouble with this myself, because ServiceStack swallowed the exceptions, and the logs, as you said, don't show the Errors collection. There are two ways to get that information:
Uncheck Enable Just My Code in the debugging options in Visual Studio (Debug -> Options and Settings). If you have checked Thrown for Common Language Runtime Exceptions in Debug -> Exceptions, you will get the exceptions, and be able to view the Errors collection.
A merge was committed some days ago to the ServiceStack repository, which makes it log the Errors collection. Demis Bellot apparently pushes new versions to NuGet fairly often, so it'll probably be there in a week or two.
I had the same problem. And my case, I have removed some libraries referenced in the project but the reference to them remained (eventhought I think removed it, but anyway) and this has been the problem.
After I deleted the references to libraries which don't exsits anymore in the project, it worked immediatelly.
I have been using Netbeans 6.1 for a long time and my debugger has always been flawless. Somehow recently (within the last two weeks or so) my debugger stops at breakpoints but it either freezes most of the time or i can't find out the value of any variable, my local variables wont expand and my watches will sometimes show all nulls even for this.hashCode() or not even update at all and freeze.
When this happens i see the following netbeans exceptions
com.sun.jdi.InternalException: Unexpected JDWP Error: 502
at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:47)
at com.sun.tools.jdi.ObjectReferenceImpl.invokeMethod(ObjectReferenceImpl.java:379)
at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.invokeVirtual(TreeEvaluator.java:164)
at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:844)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.invokeMethod(AbstractObjectVariable.java:417)
at org.netbeans.modules.debugger.jpda.ui.models.JavaVariablesFilter.getChildren(JavaVariablesFilter.java:133)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getChildren(VariablesTreeModelFilter.java:193)
at org.netbeans.spi.viewmodel.Models$CompoundTreeModel.getChildren(Models.java:628)
at org.netbeans.spi.viewmodel.Models$CompoundModel.getChildren(Models.java:2819)
at org.netbeans.modules.viewmodel.TreeModelNode$TreeModelChildren.evaluateLazily(TreeModelNode.java:701)
at org.netbeans.modules.viewmodel.TreeModelNode$LazyEvaluator.run(TreeModelNode.java:1124)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
com.sun.jdi.InternalException: Unexpected JDWP Error: 502
at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:47)
at com.sun.tools.jdi.ObjectReferenceImpl.invokeMethod(ObjectReferenceImpl.java:379)
at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.invokeVirtual(TreeEvaluator.java:164)
at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:844)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:315)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:285)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel.getLimitedToString(VariablesNodeModel.java:316)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel.getShortDescriptionSynch(VariablesNodeModel.java:275)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel$1.run(VariablesNodeModel.java:233)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Does anybody know how to fix or workaround this problem? I have googled this exception but can't find anything of value. The only thing i found is about running two different JVMs, one to debug and one to run the application (but this is not the case for me, both JVMs are the exact same version "1.4.2_03"). I am running into this issue at work so upgrading Java or my IDE is not an option, though it this was fixed in a newer version of the IDE i would still like to know that but most importantly I really need a fix or workaround for this. I have also not changed any settings in my project or NetBeans that i am aware of from the time my debugger was working to now.
Thanks
Append: I also got the following message
A com.sun.jdi.InternalException exception has occurred.
Please report this at http://www.netbeans.org/community/issues.html,
including a copy of your messages.log file as an attachment.
The messages.log file is located in your C:\Documents and Settings\default.netbeans\6.1\var\log folder.
And i have a copy of messages.log if anyone wants me to post it.
I also tried debugging with a different project that i haven't used in a while and it still failed in the same way.
I could really use some help on this one.
It's probably issue # 136461. If the software update(s) for 6.1 do not fix it, then you're probably out of luck. NB 6.1 is over 2 years old at this point.
I understand the desire to keep all developers on the same IDE release. A change to a .form file or a nbproject file can spoil an unwary developer's day.
However, can you install a personal copy of 6.9 and just use it for debugging? Keep the 6.1 around to verify everything before committing.