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

better error for mistakely doing && instead of and #1877

Closed
andrewrk opened this issue Jan 13, 2019 · 2 comments · Fixed by #1886
Closed

better error for mistakely doing && instead of and #1877

andrewrk opened this issue Jan 13, 2019 · 2 comments · Fixed by #1886
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Milestone

Comments

@andrewrk
Copy link
Member

Here's an example use case thanks to @vegecode:

const std = @import("std");
const assert = std.debug.assert;

pub const CursorPos = struct {
    row_pos: usize,
    col_pos: usize,
};

fn scanRowColumnPositionResponse(response: []const u8) !CursorPos {
    // expected response: 'ESC' '[' rows ';' columns 'R'
    if (mem.compare(u8, response, ESC ++ "[") != mem.Compare.Equal) {
        return VTError.UnexpectedResponse;
    }

    const delimiter_index = mem.indexOf(u8, response, ";") orelse return VTError.UnexpectedResponse;
    const row_pos = try fmt.parseUnsigned(usize, response[2 .. delimiter_index - 1], 10);
    const col_pos = try fmt.parseUnsigned(usize, response[delimiter_index + 1 ..], 10);

    return CursorPos{
        .row_pos = row_pos,
        .col_pos = col_pos,
    };
}

test "scan row/column position response" {
    const ESC = "";
    const ret1 = scanRowColumnPositionResponse((ESC ++ "[20;30")[0..]) catch unreachable;
    assert(ret1.row_pos == 20 && ret1.col_pos == 30);
}

The error you get is:

test.zig:28:28: error: integer value 20 cannot be implicitly casted to type '*const usize'
    assert(ret1.row_pos == 20 && ret1.col_pos == 30);
                           ^

Which is not at all clear what's actually happening: that the programmer accidentally used && instead of and.

I believe that & followed by another & would never be valid semantically, so the parser can reject this and say "did you mean and?"

@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Jan 13, 2019
@andrewrk andrewrk added this to the 0.5.0 milestone Jan 13, 2019
@andrewrk andrewrk added the contributor friendly This issue is limited in scope and/or knowledge of Zig internals. label Jan 13, 2019
@daurnimator
Copy link
Collaborator

daurnimator commented Jan 13, 2019

Yes please! I've made the same mistake (see #1737)

@emekoi
Copy link
Contributor

emekoi commented Jan 14, 2019

related too: #1560.

kristate added a commit to kristate/zig that referenced this issue Jan 25, 2019
kristate added a commit to kristate/zig that referenced this issue Jan 25, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.4.0 Apr 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contributor friendly This issue is limited in scope and/or knowledge of Zig internals. enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants