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

Formatting can incorrectly break interval literals #51

Closed
bbannier opened this issue Mar 27, 2023 · 3 comments · Fixed by #66
Closed

Formatting can incorrectly break interval literals #51

bbannier opened this issue Mar 27, 2023 · 3 comments · Fixed by #66
Labels
bug Something isn't working

Comments

@bbannier
Copy link
Member

The formatter always prefers to format interval literals with a space between value and unit, e.g., 1 min instead of 1min. It then considers the whitespace a potential line break, even though this produces invalid source code, e.g.,

$ cat bla.zeek
event zeek_init()
	{
	local aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa = 1min;
	vector(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 5 min);
	}

$ zeek-format bla.zeek
event zeek_init()
	{
	local aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa = 1
	    min;
	vector(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 5
	    min);
	}

$ zeek bla_formatted.zeek
error in ./bla_formatted.zeek, line 4: syntax error, at or near "min"
@ckreibich
Copy link
Member

I think @stevesmoot also encountered this, and I believe @Mohan-Dhawan did too (a good while ago). I fully agree that we should of course never format this way.

I took a quick look at Zeek's scanner and it treats this similarly to subnet ranges, which actually surprised me — it's happy to parse "192.168.0.0 /24", for example.

@stevesmoot
Copy link

or format them with an unbreakable space,if thats supported.

@bbannier
Copy link
Member Author

bbannier commented Nov 7, 2023

I took a quick look at Zeek's scanner and it treats this similarly to subnet ranges, which actually surprised me — it's happy to parse "192.168.0.0 /24", for example.

We currently have #29 open for exactly that, but I believe the issue is different there; I left a comment over there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants