Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

column!() should start at 1 not 0 #46868

Closed
dtolnay opened this issue Dec 20, 2017 · 1 comment
Closed

column!() should start at 1 not 0 #46868

dtolnay opened this issue Dec 20, 2017 · 1 comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Dec 20, 2017

In #46762 we noticed that column numbering is handled inconsistently throughout Rust. As of 1.22, panic columns are reported starting with 0.

fn main() {
panic!("line 2 column 0");
}

Except panics that originate within the compiler which seem to start with 1, at least in the following case.

fn main() {
let mut array = [];
array[7] = "line 3 column 1";
}

For #46762 we decided to at least make all panics consistent and go with 1 based. Discussed with the libs team today and we would be interested in applying the same fix for the column!() macro as well. Currently the first line!() is 1 and the first column!() is 0. This seems like an oversight. We would like to make column!() return 1 in the first column. This matches how panics report the column as of #46762, and matches how most text editors number columns.

Obviously if this change turns out to cause major problems then we would revisit, but column!() is used infrequently enough and its uses tend to be such that off-by-one is not important (pretty much limited to error reporting) so we are not too worried.

Documentation for both line!() and column!() will need to be updated to be explicit about the numbering.

@est31 would you be interested in tackling this change?

@dtolnay dtolnay added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Dec 20, 2017
@est31
Copy link
Member

est31 commented Dec 20, 2017

would you be interested in tackling this change?

Definitely! We'll only have to coordinate with #46762 as if they get merged in the wrong order we might get into issues :). I'll have a look at this at friday.

bors added a commit that referenced this issue Dec 27, 2017
 Make the output of the column! macro 1 based

Fixes  #46868.

I didn't add any regression tests as the change already had to change tests inside the codebase.

r? @dtolnay
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants