I am struggling to prevent IDEA from complaining about assignment to variable declared by def keyword.
The assignment is absolutely safe as far as I can tell (I observe the same for literals of other types assigned to defed variables). I do not see why assigning Integer into Object would be a problem in the first place.
There does not seem to be any explanation in inspections settings (Groovy > Assignment issues > Incompatible type assignments) nor any fine grained configuration to tune this. When turned off completely, it stops reporting real problems like Integer a = "" as well.
How do I get it to report real problems without highlighting safe assignments?
IntelliJ IDEA can not relay grok the groovy code unless there are both Groovy and Java SDKs configured. By importing the project Groovy got configured automatically, but Java did not.
Related
I tried to use the community version of IntelliJ IDEA for a proprietary scripting language similar to Java (and I don't do actual Java development for now) which generally works quite well regarding simple refactoring and type hinting.
Because of mainly two differences in the language (boolean is bool and the API calls don't expect java.lang.String types but API specific ones) each class file is contaminated with several errors, which make it useless to quickly find actual errors in that scripting language using IDEA's inspections.
Examples (shown error by IDEA in the comment):
bool boolTypeVariable = true; //cannot resolve symbol bool
if(boolTypeVariable) //Incompatibles types: required boolean, found bool
nlvm.lang.String str = "a String"; //Incompatibles types: required nlvm.lang.String, found java.lang.String
(Other errors arise when using !bool, bool && bool and so on)
Is it possible to ignore just these specific kind of inspections or preferably make IDEA to inspect these as desired with small modifications?
I'm aware that it's possible to define own languages for IntelliJ but I'm mostly targeting for some quick solution (which can be dirty, if it works for that case)
I would also accept a suggestion for another IDE that does supports type hinting, inspections and some basic refactoring when it's easily possible to achieve this there (I just choose IDEA community for that since I'm familiar with PyCharm).
If disable inspection intention action is not available it means the error is reported either by the parser (such syntax is not supported) or a validation that can not be disabled (e.g. the class bool that must be present in the classpath (i.e. in JDK or module libraries or the javac would report the error). To completely remove validation errors you can disable highlighting for the file.
I have an errors.rs file with error_chain! {}, which exports Result, ResultExt, Error and ErrorKind.
If I use self::errors::*, IntelliJ thinks that I'm using the default Result (std::result::Result, I think). However, if I explicitly import the types using use self::errors::{Result, ...}, everything works out hunky dory.
I can tell because the standard result has two type params, but the error_chain one has only one.
In either case, it still compiles.
I'm using the standard Rust IntelliJ plugin, version 0.1.0.1991.
Help! Does anyone know how to get the plugin to understand what the macro is doing?
The IntelliJ-Rust plugin uses its own code parser. It allows to leverage all the IntelliJ platform capabilities (like code navigation, formatting, refactoring, inspections, quick documentation, markers and many others) but requires implementing all the language features, which is not a simple task for Rust (you can find a more in-depth discussion of the Rust compiler parser versus IDE parser in this reddit post).
Macros expansion is probably the biggest language feature that is not supported by the plugin parser at the moment. That is, the plugin sees this error_chain! call, can resolve it to its definition, but doesn't expand it to the actual code and hence doesn't know about the new Result struct that shadows the one from stdlib. Unfortunately, in some cases it leads to such false positive error messages.
I've converted this error annotation into an inspection, so in the next plugin version you'll be able to switch it off entirely or for the particular code block. The work on macros expansion is also in progress.
While trying to learn Frege I copied some code from Dierk's Real World Frege to the online REPL an tried to execute it (see also How to execute a compiled code snipped in Frege online repl). The scripts I've tried don't compile :-(
What am I doing wrong?
Here are examples of what does not compile:
println ( 2 *-3 ) -- unlike haskell, this will work!
and the whole ValuesAndVariables.fr code
It is unavoidable that over the course of more than a year, an evolving language (and its libraries) change so that older code will not compile anymore.
It would be nice, if we could see an example, instead of a generalization like "most".
The next best thing would be to have an issue in Dierks project that points to the error(s).
But the very best would be en effort to find out what is wrong. This would also intensify your learning process.
Here are two ressources that could help:
https://github.com/Frege/frege/wiki/New-or-Changed-Features -- the release notes for every release, contains a summary of things that have changed between releases, and especially the reasons why code would not compile anymore and how to correct it.
http://www.frege-lang.org/doc/fregedoc.html -- the library docs. May explain possible errors like import not found, or missing identifiers.
Go, give it a try. And I'm convinced Dierk will be happy to accept pull requests.
Edit: Fixes for announced errors.
The error in:
println ( 2 *-3 )
stems indeed from a syntactical change.
It is, as of recently, demanded that adjacent operators be separated by at least one space.
Hence
println (2 * -3)
However, the error message you got here was:
can't resolve `*-`, did you mean `-` perhaps?
which could have triggered the idea that it tries to interpret *- as a single operator.
The other error in ValuesAndVariables1.fr is indeed a show stopper for a beginner. The background is that we have one pi that has type Double and one that has type Float and potentially many more through type class Floating, so one needs to tell which one to print.
The following will work:
import Prelude.Math -- unless already imported
println Float.pi
println (pi :: Double)
the online REPL at http://try.frege-lang.org is currently based on Frege V3.23.370-g898bc8c . Dierk's code examples are based on V3.21.500-g88270a0 (which can be seen in the gradle build file).
It seems that the Frege developers decided to change the Frege syntax slightly between those versions. THe result is that you will not be able to run these code snippets in the online REPL anymore.
Is there a lint for Elixir (like for Javascript) which checks that every function has a type specification?
There is an Erlang compiler switch, +warn_missing_spec, which does this, but I'm having trouble getting it to work with Elixir at the moment, I think there is a bug with it's parsing of the ELIXIR_ERL_OPTS environment variable which is converting +warn_missing_spec into -warn_missing_spec which isn't a valid compiler option. I'm going to open an issue on the tracker, but thought you might like to know that this does indeed exist.
EDIT: As José mentioned below, the correct flag is ERL_COMPILER_OPTIONS. You can enable the missing spec warning during compilation by doing the following:
ERL_COMPILER_OPTIONS="warn_missing_spec" mix compile
Keep in mind you may get superfluous warnings from Elixir itself, for functions like __MODULE__. It should still be useful though. One last thing to note, I discovered this morning that there is a problem using this flag with mix compile, and that it's currently only warning about mix.exs. This is being fixed, and may even be fixed by the time you see this, but it's something to be aware of.
This is what I'm doing:
extract contents of my JRE's rt.jar
extract src.zip of my JDK (same version)
Now, if I copy Runtime.java from the extracted src folder and compile it using javac.exe without any modifications and then put it in the extracted rt folder to finally put everything back in a jar file using jar.exe, everything works as expected. The JRE runs fine.
However, if I make the slightest change to Runtime.java and compile it and put it in rt.jar, the JRE crashes whenever I attempt to start it. This is an example of a slight change that causes the silent crash:
/** Don't let anyone else instantiate this class */
private Runtime() {
System.out.println("This is a test.");
}
Instead of:
/** Don't let anyone else instantiate this class */
private Runtime() {}
Could anyone tell me why this is causing my JRE to crash?
Thanks in advance.
It's possible that System.out has not been initialised at the time that the Runtime() constructor runs. Usually console output is not considered a "slight" change, but at the wrong time it can invoke way too much stuff that may not be set up at all yet.
You're doing this all wrong. You can't distribute that modified JRE for a start, so it is only useful inside your organization . Install a SecurityManager and don't grant your codebase any of the RuntimePermissions you're trying to protect against.
#Tom - I advise you NOT to try to do this:
You cannot distribute the modified rt.jar file without violating the Sun binary license.
Even if you did, you would not be allowed to call it Java.
As you are finding, there are lots of complications that arise when you make changes, particularly when those changes might interfere with the JVM's behind the scenes initialization. And when things blow up during initialization, the JVM often cannot report the problem in an intelligible way.
If you do succeed in making the modified rt.jar work for one JRE, there is no guarantee that the same hacks will work for a different version.
Nobody in their right mind would knowingly use a modified JVM (especially one modified by a third-party) in a production app.
EDIT : judging from your other questions, I guess you are trying to reverse engineer or modify some third party Java application with a custom launcher. If you provided more information on what you were really trying to do, we might be able to suggest the right way to do it ... rather than using "desperate measures" such as modifying the JRE.
That's pretty strange, as I did the same trick with many classes in rt.jar in past.
Can you provide us with the crashed process output?