Hey,
First of all thanks for the feedback, I love seeing it.
For the STC problem, I just did a quick test and I do not get STC errors for this code:
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.Issue
import mycompany.Util
Issue issue
MutableIssue mutableIssue
Util.method1(issue)
Util.method2(mutableIssue, true)
If you try to call method2
with Issue
that would be a type checking error because MutableIssue extends Issue
. If you have determined that your object is an instance of MutableIssue
you can cast inline e.g Utils.method2(issue as MutableIssue, true)
It is possible I’m not fully understanding your problem, if you could provide an example that fails STC that would be very helpful. Groovy is a dynamic language and STC can fail for code that will execute properly at runtime, to get green STC you usually will need to help the compiler out by providing more information about your types.
- Type “import com.”, then Ctrl-space.
- Nothing is suggested.
We don’t yet have support completions of import statements, I think this is generally because our team members usually reference the class in the script and then use the auto import quick fix. We are aware that others manually type imports though.
We have discussed adding the import statement completions, I’m sure we will add it in the mid term.
Alternatively, type “ComponentAcc”, then Ctrl-space. After loading a while, “No suggestions”.
I cannot reproduce this, it’s possible I am doing something wrong
But it will add the import statement above the package statement, breaking the script.
This is a nasty bug, I recall having test coverage for this and am surprised to see such a regression, I will ask somebody to fix this in the next release cycle.
Any error in the script will break context-help.
This is a very tricky problem, STC errors in general shouldn’t completely break code completions, but syntax errors can.
Ultimately the code completions require the Groovy compiler to be able to parse the code, we have various “hacks” to make incomplete source code parse, for example if you type Foo.
this is invalid syntax, but you should still see code completions for methods on the class.
In ScriptRunner 7.2.0 we tweaked the Groovy parser to not fail on the first syntax error https://productsupport.adaptavist.com/browse/SRPLAT-2055, this improves things more e.g if (|)
should get completions now, although I have spotted some cases where it does not, there is no perfect solution here.
If you could provide minimal code snippets that break code completions I would really appreciate it, I cannot guarantee we will be able to fix them easily, but we are heavily investing into the editing experience within the app.
The in app editing experience is drastically improved from where we were last year, and we are constantly tweaking and fixing bugs, we’re never going to be IntelliJ, but we continue to innovate based on user feedback.
In some cases the in app experience is superior to an IDE, for example we can provide inline completions for custom field names/IDs because the code completion backend runs within Jira, there is a lot more stuff like this on the roadmap
I hope I’ve given you more context on your valuable feedback, happy to discuss the points in more detail, I will be transparent that the code completion support is not perfect, but we can improve with help from customers.
Cheers!
Reece