crystal-ameba / ameba

A static code analysis tool for Crystal

Home Page:https://crystal-ameba.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ameba seems to incorrectly show what the line that needs fixing is

weirdbricks opened this issue · comments

I have this file: src/plugins/ameba1.cr with content:

require "process"

def run_cmd(cmd)
  stdout = IO::Memory.new
  stderr = IO::Memory.new
  status = Process.run(cmd, output: stdout, error: stderr,shell: true)
  if status.success?
    {status.exit_code, stdout.to_s}
  else
    {status.exit_code, stderr.to_s}
  end
end

I run Ameba against it:

ameba src/plugins/ameba1.cr 
Inspecting 1 file

F

src/plugins/ameba1.cr:1:1 [Correctable]
[W] Lint/Formatting: Use built-in formatter to format this source
> require "process"
  ^

Finished in 2.34 milliseconds
1 inspected, 1 failure

It seems to point to the very first line --- but when I re-run it with fix:

cp src/plugins/ameba1.cr src/plugins/ameba_before_fix.cr
ameba --fix src/plugins/ameba1.cr

Output:

Inspecting 1 file

F

src/plugins/ameba1.cr:1:1 [Corrected]
[W] Lint/Formatting: Use built-in formatter to format this source
> require "process"
  ^

Finished in 3.59 milliseconds
1 inspected, 1 failure

But diff disagrees on what Ameba actually fixed:

diff src/plugins/ameba1.cr src/plugins/ameba_before_fix.cr
6c6
<   status = Process.run(cmd, output: stdout, error: stderr, shell: true)
---
>   status = Process.run(cmd, output: stdout, error: stderr,shell: true)

Am I doing something wrong or is this a bug ? I would expect Ameba to show that the spacing between stderr, and shell was incorrect, but instead it seems to point out that there's a problem with: require process

In case it helps:

ameba --version
1.4.3
crystal --version
Crystal 1.8.1 [a59a3dbd7] (2023-04-20)

LLVM: 15.0.7
Default target: x86_64-unknown-linux-gnu
cat /etc/issue
Ubuntu 22.04.2 LTS \n \l

That's not a bug. Due to how the Crystal formatter works, Ameba can only show the error in the scope of the whole file.
Also, this concerns only Lint/Formatting rule.

@Sija maybe we can remove that :1:1 at the end for this specific rule in order to avoid confusion?

@veelenga Since the Ameba's issues are attached to the Location I don't see any clean way to do it.

Oh, well, actually we could show the line(s) with changes, but how would that work?

  • Show just the first line changed?
  • Show all of the lines changed, each one tagged as Lint/Formatting issue?

My idea is to have a new rule prop, let’s say scope which could be Point | Line | File and which defaults to Point. The formatter rule will override it to File. Then each Ameba’s formatter will properly format the output. What do you think?

However, it may break the flycheck formatter which is used by editors to point to the location.