For count % 2 I get the warning
Warning:(137, 17) Kotlin: 'mod(Int): Int' is deprecated. Use rem(other) instead
and the Intellij IDE provides for an automated correction to count.rem(2) which I then get flagged as an error due to an unresolved reference to rem.
What am I doing wrong?
This is a known bug in the Kotlin IDE plugin.
It arises from the deprecation of the mod function in Kotlin 1.1, which should be replaced by rem (see Other changes in this blog post). But the IDE plugin incorrectly reports and suggest the quick fix even for earlier Kotlin versions which didn't have rem.
Unitl it is fixed, you can either update your project to Kotlin 1.1 or suppress the warnings, or just ignore them.
Related
Simply, we are very sensitive to ABI changes, and we want to prevent people on our team using experimental features because of issues this can cause at runtime. Is there a way either via gradle configuration and/or a custom gradle plugin to detect when such features are used and elicit a compiler warning, preferably with a custom error message?
The Kotlin compiler (and transitively Gradle) will warn you by default (or even show an error) when experimental features are used.
To change this behaviour, the developer has to opt in via an #OptIn annotation or -opt-in compiler argument. If you're trying to avoid accidental usages of experimental features, this should therefore be sufficient (if we consider that opting in to an experimental feature is not an accident).
If you want to prevent usages of #OptIn itself, this is a different story. Technically #OptIn itself is still experimental at the moment, so there will be a warning for usages of it anyway unless someone adds the compiler argument to opt in to the #OptIn experimental annotation :) So currently just having a culture of not modifying compiler arguments should be enough, but that of course will change once #OptIn gets stable.
I am not aware of plugins that already do this, but you should be able to write a plugin with Kotlin Symbol Processing that checks for those annotations (never tried it myself, though).
As a side note about ABI compatibility, there is also the binary-compatibility-validator, but that's for your own code, so I don't think it's related to the question.
Going off the documentation here are Modules and other Geb DSL not expected to be recognized within a Spock Spec with IntelliJ? This makes using Geb with IntelliJ a bit cumbersome with no DSL reference. I noticed from this question that the asker did some custom work to get IntelliJ to wrap and notice the Geb DSL.
My questions is am I doing something wrong or is this expected and has there been any progress on getting the Geb DSL recognized by IntelliJ?
If not does anyone have a workaround for this issue/limitation and or another IDE that does recognized the Geb DSL?
IntelliJ has support for Geb DSL, I've been using it for years and there are even tests in IntelliJ's codebase that confirm it's there.
If you could share how your code looks like and what exactly does not work for you then maybe we can find a problem with your setup or expectations. It would also be good to know whether you are using community edition or professional edition.
Please note that the issue discussed in the question you linked to has been fixed by me in this PR and is no longer present since IntelliJ 2018.2.
EDIT:
After reading your comments under my response I now understand what the problem is. Your expectation is that IntelliJ will be able to figure out what the page type at runtime is and provide you with autocompletion. I'm afraid that is simply not possible - you need to track current page instance in your code for IntelliJ to be able to infer types.
Note that tests in geb-example-gradle are written in the very concise, yet dynamic style which means that IntelliJ is not able to infer types. What you need to do is to use the strongly typed style as described in the documentation. That section of the docs could do with a bit of improvement because it's not precise - I've created a Github issue to track that.
Essentially, if you tweak GebishOrgSpec from geb-example-gradle to:
class GebishOrgSpec extends GebSpec {
def "can get to the current Book of Geb"() {
when:
def homePage = to GebishOrgHomePage
and:
homePage.manualsMenu.open()
then:
homePage.manualsMenu.links[0].text().startsWith("current")
when:
homePage.manualsMenu.links[0].click()
then:
at TheBookOfGebPage
}
}
then IntelliJ will provide you with autocompletion.
I want to print some special characters(Latin, Greek alphabet, Chinese, etc) in Kotlin, but always got ??????? as the output:
>> println("Δ")
>> ??????
Also tried unicode:
>> println("\u0394")
>> ?
IDE I used: IntelliJ IDEA 2018.1.3.
Console I used: Kotlin REPL.
jdk: 9.0.4
Kotlin version: 1.2.31 (JRE 9.0.4+11)
How could I print the right string?
Update(20180512):
I also tried to install Kotlin via Homebrew and run kotlinc in my own terminal, it works as expected. It just doesn't work in Kotlin REPL of IntelliJ. Any place I can go to fix that?
Update(20180513):
Tried the followings:
Clear IntelliJ cache;
Reinstalled IntelliJ;
Make IntelliJ and Kotlin up to date;
Restart MacOS(10.12.6);
Update Java to 10.0.1.
Used println in Kotlin REPL again, ??? changed to the specific error:
println("Δ")
Internal error occurred. Please, send report to developers.
exception: java.nio.charset.MalformedInputException: Input length = 1
at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:281)
at kotlin.io.ConsoleKt.tryDecode(Console.kt:198)
at kotlin.io.ConsoleKt.readLine(Console.kt:162)
at kotlin.io.ConsoleKt.readLine(Console.kt:149)
at org.jetbrains.kotlin.cli.jvm.repl.reader.IdeReplCommandReader.readLine(IdeReplCommandReader.kt:22)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.one(ReplFromTerminal.kt:98)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.doRun(ReplFromTerminal.kt:69)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal.access$doRun(ReplFromTerminal.kt:38)
at org.jetbrains.kotlin.cli.jvm.repl.ReplFromTerminal$Companion.run(ReplFromTerminal.kt:175)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:105)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:63)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:107)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.java:51)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:96)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:72)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:38)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit(CLITool.kt:171)
at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMain(CLITool.kt:162)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler$Companion.main(K2JVMCompiler.kt:329)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.main(K2JVMCompiler.kt)
Internal error occurred. Please, send report to developers.
Process finished with exit code 2
It seems the reading character encoding is different from writing encoding. But I can find no way to config the encoding of Kotlin REPL.
And also, I found 2 java processes running while I open Kotlin REPL and every time I have to kill one to run Kotlin REPL smoothly:
image: 2 java processes running
I'm not sure if they are related, so I attached the image as a reference. Already reported to IntelliJ developers, but it seems not a common bug for most people.
Try to run println("\u0394"). If that works, your file likely isn't in the UTF-8 encoding. If it doesn't, there's an issue with your terminal.
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.
I have a new Java project started that is using Gradle (version 3.4.1) and IntelliJ. I used gradle init at the command line and then imported the project into IntelliJ, using the default wrapper (which is recommended, according the the IDE).
I have the following in the build.gradle file:
jar {
manifest {
attributes 'Main-Class': "com.testerstories.textadv.Voxam"
}
}
The attributes line, however, provides a consistent warning that says:
'attributes' cannot be applied to '(['Main-Class':groovy.lang.GString])'
The issue appears to be "incompatible types." But it's unclear what "attributes" is being "applied to". I would presume the manifest block. But then ... what does it want me to do exactly?
I realize this is a warning and I could just ignore it. I also realize I can block inspections. But in all the discussions about this, and I realize there are a few (although most of those seem to deal with 'groovy.lang.Closure'), I have yet to find anything that unambiguously states quite simply what the actual issue is and how to resolve it. I say "resolve it" in contrast to (1) just cover it up or (2) pretend it doesn't exist.
It concerns me that something that appears to be very basic Gradle usage is not recognized or is indicating a problem in one of the core IDEs that supports Java.
Finally, I'll note that before adding to the StackOverflow space, I had asked JetBrains support and their answer was to make sure my .iml file was indicating a "JAVA_MODULE" rather than a "WEB_MODULE", which I did verify. Their next answer was that I needed to provide (quoting directly) a "namespace to resolve the ambiguity, which should resolve erroneous type errors." Ironically, perhaps, that reply needed some ambiguity resolution of its own, but I have gotten no further responses.
UPDATE (RELATED TO ABOVE; BUT DIFFERENT CONTEXT)
If I use something like this in my Gradle:
systemProperties(System.getProperties())
I'm told that getProperties() is an ambiguous method call. Originally I thought that was unrelated to my original issue, but the IntelliJ inspector reports that this is also an issue with incompatible types.
The conclusion I'm reaching -- and what will probably be the "answer" -- is that Gradle and IntelliJ just don't play nice with each other in a variety of contexts.