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.

Sign up for GitHub

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

Jump to bottom

"expected identifier" error for date-like table name #571

Open
Garmelon opened this issue Feb 24, 2024 · 1 comment · May be fixed by #749
Open

"expected identifier" error for date-like table name #571

Garmelon opened this issue Feb 24, 2024 · 1 comment · May be fixed by #749
Labels
bug Something isn't working

Comments

@Garmelon
Copy link

Garmelon commented Feb 24, 2024 •
edited
Loading

When opening a toml file containing the following table, the plugin reports the error "expected identifier":

[2024-01-01]

image

According to the toml spec for tables,

Naming rules for tables are the same as for keys (see definition of Keys above).

Checking the toml spec for keys, we find that

A key may be either bare, quoted, or dotted.

Bare keys may only contain ASCII letters, ASCII digits, underscores, and dashes (A-Za-z0-9_-). Note that bare keys are allowed to be composed of only ASCII digits, e.g. 1234, but are always interpreted as strings.

Following that definition, the key 2024-01-01, even though it looks like a date, is a valid key equivalent to the quoted key "2024-01-01". The vscode plugin recognizes this because using it as a normal key instead of a table key works without errors:
image

This appears to be date-specific. Invalid dates or keys that look like other values don't cause errors.
image

I am using version 0.19.2 of the tamasfe.even-better-toml VSCode extension.
@tamasfe tamasfe added the bug Something isn't working label Feb 24, 2024
@Garmelon
Copy link
Author

Garmelon commented Feb 20, 2025 •
edited
Loading

After a quick experiment, this might be a bug in the tokenizer library used by taplo, logos version 0.12.0. The bug persists even in the latest version of logos, namely 0.15.0.

2024-01-01 in identifier position is lexed as INTEGER, which has the definition

    #[regex(r"[+-]?[0-9_]+", priority = 4)]
    INTEGER,

Of course, the regex does not match 2024-01-01 at all.

Removing the DATE_TIME_OFFSET and DATE_TIME_LOCAL variants from SyntaxKind results in the identifier (correctly) being parsed as a DATE instead. This also points to it being a weird bug in logos.

A fix for taplo might be to convert DATE to IDENT in parse_ident, similar to this:

taplo/crates/taplo/src/parser/mod.rs

Line 507 in 18b86da

INTEGER_HEX | INTEGER_BIN | INTEGER_OCT => self.token_as(IDENT),

Possibly related to maciejhirsz/logos#461

@Garmelon Garmelon linked a pull request Feb 20, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow dates in identifiers Garmelon/taplo
2 participants
@Garmelon @tamasfe