How can I configure Android Studio/IntelliJ Idea to show more than 101 error messages when compiling?
I know there are more than 101 errors, but I am using Android Annotations and I get a lot of import errors when something is wrong. Those import errors fill up the messages window and I can't see the actual errors that need to be fixed.
Thanks!
This 101 error limit is imposed by the underlying compiler , not the IDE. So to increase it, you have to change the default compiler settings.
Go To : Preferences -> Build, Execution, Deployment -> Compiler.
There, you'll find an option of passing additional command line options to the compiler. There you can change the max errors limit.
The compiler used by Android studio is javac and it offers the following options :
-Xmaxerrs number : Set the maximum number of errors to print.
-Xmaxwarns number : Set the maximum number of warnings to print. `
So, you can pass :
-Xmaxerrs 400 -Xmaxwarns 1000 to make the maximum errors reported to 400 and maximum warnings reported to 1000.
That's one way to do it in IDE UI and change it globally for all projects.
You can also set this for a specific project by passing these command line options to the compiler through the gradle file of the project. Here's the syntax for that:
gradle.projectsEvaluated {
tasks.withType(JavaCompile) {
options.compilerArgs << "-Xmaxerrs" << "400" << " -Xmaxwarns" << "1000"
}
In Gradle, change the allprojects of your Project build.gradle as following:
allprojects {
repositories {
jcenter()
}
// Allow 400 errors.
gradle.projectsEvaluated {
tasks.withType(JavaCompile) {
options.compilerArgs << "-Xmaxerrs" << "400"
}
}
}
As everybody pointed out, maximum errors displayed is a Compiler rather than an Android Studio setting. I am using kotlin annotation processor kapt for incremental compilation of databinding, room and dagger. The following addition to build.gradle solved the problem:
kapt {
javacOptions {
// Increase the max count of errors from annotation processors.
option("-Xmaxerrs", 500)
}
}
Hope it helps someone, when applying the various other options suggested I kept seeing 50 errors.
I don't know, how to force Messages window show more than 101 errors, but maybe this would help.
At the end of Messages window you can see:
Or you can call console from icon:
Here how it looks:
I believe you can find all information there.
Also there is a possibility to export log to text file, this also might help you.
Thanks.
Add the Android Annotations Support JAR to your build.gradle -
compile 'com.android.support:support-annotations:23.3.0'
This should get rid of the import errors.
Related
I write a Groovy script and I need to access a field that has a private access modifier. This works fine but generates a warning:
Access to <field_name> exceeds its access rights
I want to supress this warning. What value of #SuppressWarnings annotation do I have to use in order to achieve it?
I've tried #SuppressWarnings("all") and it works fine but I would like to have more granular control over suppressions. I've also tried #SuppressWarnings("AccessingNonPublicFieldOfAnotherObject") but it has no effect.
Below how this warning looks in IntelliJ:
Unfortunately automatic hint doesn't suggest any sensible solution:
If you are talking about IntelliJ warning:
then you can hit Alt+Enter on the offender and choose "Suppress for method" as follows:
after which you will see #SuppressWarnings("GroovyAccessibility") over your test method:
I had this "problem" when I had buildSrc folder in Gradle-project which contained Kotlin code for my Gradle build scripts and it was used in Groovy code.
Seems like it was because I was accessing private variable field and not the getter. Kotlin makes field private by default. I solved this by using #JvmField in Kotlin code which makes the variable field public and does not generate getter for that field.
// groovy in gradle build script
compileOptions {
sourceCompatibility(CompileOptions.javaVersion)
}
// kotlin in buildSrc (this gives the warning)
object CompileOptions {
val javaVersion = JavaVersion.VERSION_11
}
// kotlin in buildSrc (this does not give the warning as field is now public)
object CompileOptions {
#JvmField val javaVersion = JavaVersion.VERSION_11
}
In my Android project I have an external library with following method:
// Some external library
class Foo {
#CheckReturnValue
public final Bar returnBar(Bar bar) {
...
}
}
I have to call this method a lot in my project, but I do not need the returned value of this method. All I need is the side effect of the method. So this is how I use it:
fooInstance.returnBar(barInstance) // ignore returned value
The problem with the above code is that Android Studio editor will show CheckResult warning lint. What I can do is to either just live with that warning lint or disable CheckResult for the entire project or module, but I was wondering if there is a better approach to this warning.
What I cannot do is to put SuppressLint because I will be using that method 100 < times in my project and adding SuppressLint to every single usage is not really feasible.
I already went through Android Studio inspection settings but unfortunately was not able to find anything that can help. I would be grateful if you could provide literally any thought on this problem.
Android gradle plugin generates tons of .rawproto files in build/android-profile directory. What are they used for? Is there a way to disable this madness or automatically delete them?
I've been bugged by it for a long time, and now that I noticed there's gigabytes of this hogging my smallish SSD, I've decided to figure out a way to disable it. For me the most annoying thing before occupying too much space was gradlew clean leaving a build folder behind.
Only tested with com.android.tools.build:gradle:3.0.1, so YMMV.
TL;DR
For global application read last section, per-project use this in rootProject's build.gradle:
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
// and then `gradlew --stop && gradlew clean` to verify no build folder is left behind
Investigation
Thanks to https://stackoverflow.com/a/43910084/253468 linked by #JeffRichards mentioning ProcessProfileWriterFactory.java, I've put a breakpoint there and checked who's calling it by running gradlew -Dorg.gradle.debug=true --info (not to be confused with --debug) and attaching a remote debugger.
I followed the trail and found that ProcessProfileWriter.finishAndMaybeWrite creates the folder and writes. Backtracing on method calls I found that ProfilerInitializer.recordingBuildListener controls whether it's called ... and that is initialized directly by BasePlugin (apply plugin: 'com.android.*').
So in order to prevent anything from happening I opted to try to disable the guard, by pre-initialized that static field. Thankfully Groovy (and hence Gradle) doesn't give a * about JVM visibility modifiers, so without reflection here's the magic line:
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
I know, it's a bit verbose, but it works, and if you import stuff it looks better:
ProfilerInitializer.recordingBuildListener = new RecordingBuildListener(ProcessProfileWriter.get());
Applying the magic
In a single-project build (one build.gradle) you must apply this before
apply plugin: 'com.android.application'
In multi-project builds (most template projects: app folder, settings.gradle, and many build.gradles) I suggest you apply it around the buildscript block:
buildscript {
// ...
dependencies {
classpath 'com.android.tools.build:gradle:3.0.1'
}
}
// magic line here
Make sure it's before any apply plugin:s, and not inside a buildscript block.
Applying the magic globally
Obviously if it bothers us in one project, it will in all cases, so following Gradle's manual, create a file in ~/.gradle/init.gradle or %USERPROFILE%\.gradle\init.gradle (mind you this folder can be relocated with GRADLE_USER_HOME) with the following contents:
// NB: any changes to this script require a new daemon (`gradlew --stop` or `gradlew --no-daemon <tasks>`)
rootProject { rootProject -> // see https://stackoverflow.com/a/48087543/253468
// listen for lifecycle events on the project's plugins
rootProject.plugins.whenPluginAdded { plugin ->
// check if any Android plugin is being applied (not necessarily just 'com.android.application')
// this plugin is actually exactly for this purpose: to get notified
if (plugin.class.name == 'com.android.build.gradle.api.AndroidBasePlugin') {
logger.info 'Turning off `build/android-profile/profile-*.(rawproto|json)` generation.'
// execute the hack in the context of the buildscript, not in this initscript
new GroovyShell(plugin.class.classLoader).evaluate("""
com.android.build.gradle.internal.profile.ProfilerInitializer.recordingBuildListener =
new com.android.build.gradle.internal.profile.RecordingBuildListener(
com.android.builder.profile.ProcessProfileWriter.get());
""")
}
}
}
I'm new to groovy and gradle and was wondering whether someone knew why my scriplet wasn't working (edit actually it does work but the warning still appears). This section is taken out of the build.gradle script and intellij highlights this and complains that it: "Cannot infer argument types". any help would be nice :)
task hellofun << {
[silly:'billy'].each { k, v ->
println "$k=$v"
}
}
EDIT: I have submitted a bug request informing Intellij of this problem
EDIT: apparently this is a known bug I'll update this once the bug is fixed
If you are willing to disable the Groovy > Assignment Issues > Incompatible type assignments inspection, the warning goes away.
In a highly dynamically typed language such as groovy where names and symbols are resolved in arbitrary ways It would be quite difficult to determine the validity of any statement ahead of time without running the program. even running the program would theoretically not divulge all possible permutations of input that may change the runtime validity of a statement.
I applaud intellij's attempt at this hard problem and can live with a few incorrect syntax warnings here and there.
Untill the IntelliJ bug is fixed, there is a workaround: use doFirst instead of <<.
task hellofun() {
doFirst {
[silly:'billy'].each { k, v ->
println "$k=$v"
}
}
}
Thanks for submitting the bug :)
For the workaround, you should really call was was indicated by the << (doLast)
task hellofun() {
doLast {
[silly:'billy'].each { k, v ->
println "$k=$v"
}
}
}
In Intelij press Double shift (search all) enter "Assignment Issues" and change Assignment Issues: Incompatible type assignments inspection to "OFF"
I am trying to make a shim in VS 2012 ultimate as it described in MSDN site:
[TestClass]
public class TestClass1
{
[TestMethod]
public void TestCurrentYear()
{
int fixedYear = 2000;
using (ShimsContext.Create())
{
// Arrange:
// Detour DateTime.Now to return a fixed date:
System.Fakes.ShimDateTime.NowGet =
() =>
{ return new DateTime(fixedYear, 1, 1); };
// Instantiate the component under test:
var componentUnderTest = new MyComponent();
// Act:
int year = componentUnderTest.GetTheCurrentYear();
// Assert:
// This will always be true if the component is working:
Assert.AreEqual(fixedYear, year);
}
}
}
see http://msdn.microsoft.com/en-us/library/hh549176.aspx
But when I compile my test project I get a notion in Output:
warning : Some fakes could not be generated. For complete details, set Diagnostic attribute of the Fakes element in this file to 'true' and rebuild the project.
How can I resolve this warning?
Visual Studio 2012 Update 1 improved code generation in Fakes to simplify troubleshooting of code generation problems. Whenever a Stub or a Shim could not be generated for a particular type, Fakes can now generate a warning message - you can see this in the Error List window of Visual Studio.
However, to prevent the number of warnings from becoming overwhelming for a large assembly, such as System, Fakes generates a single warning by default. You can see a complete list of warning messages by setting the Diagnostic attribute of the Fakes XML element in the .Fakes file to "true" or "1" and rebuilding the project. (See the first line of code below for an example.)
To resolve the warning, change the .Fakes file to generate only those Stubs and Shims you need in your tests. Details here
here a complete list of available options
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/" Diagnostic="true">
<Assembly Name="System" Version="4.0.0.0"/>
<StubGeneration Disable="true" />
<ShimGeneration>
<Clear/>
<Add FullName="System.DateTime!"/>
</ShimGeneration>
</Fakes>
I have resolved it already alone.
It was .Net Framework 4.0 in Property.
Changing on 4.5 resolve the problem.
Try removing those .Fakes file.
I removed them accidentally and compiled, and the warnings are gone.
I am not sure what the impact is, but everything seems to run fine. I think it causes the compile to recompile the fakes file everything there is a build.