leanprover / leanprover/lean4

Off by one between lean build error location column vs lsp and gnu standard

Open
#2,207 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P-low
Dominant language
Lean
Stars
9.2k
Forks
990
Avg merge
1d 17h
Merged PRs (30d)
175

Description

Prerequisites
  • Put an X between the brackets on this line if you have done all of the following:
    • Checked that your issue isn't already filed.
    • Reduced the issue to a self-contained, reproducible test case.
Description

Location of errors in command line output of lake build appears off by one

Steps to Reproduce
  1. Take any file that produces an error e.g: test.lean
def   t : Nat :=
  sorry
  1. run lean test.lean

Expected behavior: Seeing as the error is shown on the function name 7th character I expect to see

./././test.lean:1:7: warning: declaration uses 'sorry'

Indeed in vscode I see an error on line 1 column 7

[{
	"resource": "/Users/alex/mathlib4-master/Mathlib/t.lean",
	"owner": "_generated_diagnostic_collection_name_#3",
	"severity": 8,
	"message": "declaration uses 'sorry'",
	"source": "Lean 4",
	"startLineNumber": 1,
	"startColumn": 7,
	"endLineNumber": 1,
	"endColumn": 8
}]

Actual behavior: the error is reported on character 6

./././test.lean:1:6: error: declaration uses 'sorry'

this is a slight inconvenience when working with standardized tools to deal with errors,
e.g. vim's quickfix or cmd+clicking build failure lines in the vscode terminal view, automatically puts me on character 6, which isn't the one I need to be to make changes (in the example above this doesn't matter but in other examples its convenient to be in the place that lean actually reports the error
also github annotations based on this error show in the wrong place.

Reproduces how often: 100%

Versions

nightly 4 20

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the report with the provided test.lean example using lean test.lean and compare its location with the VS Code LSP diagnostic and the lake build output. Trace the reported column through the command-line diagnostic entry point, then verify that CLI, LSP, and standard-tool locations agree.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.