Skip to content

Conversation

Insomniak47
Copy link

While implementing a message templates parser I pulled the message templates tests from the C# repo to ensure that my parsing behaviour was correct & translated them into rust. While I was doing that I saw that alignment was specified to be able to be any digits preceded by an optional '-' but the test ZeroValuesAlignmentIsParsedAsText indicates that the first digit should not be able to be zero.

This seems to be the intended behaviour & there isn't a consensus across the ecosystem: Your repo + serilog treat it as invalid, though I believe serilog just nabbed most of your tests and nlog treats it as valid. However given there's a specific test for it I expected that this was an oversight in the grammar definition and figured I could help either fix it here or in the tests.

While implementing a message templates parser I pulled the message
templates tests from the C# repo to ensure that my parsing behaviour was
correct & translated them into rust. While I was doing that I saw that
alignment was specified to be able to be any digits preceeded by an
optional '-' but the test "ZeroValuesAlignmentIsParsedAsText". Since
this seems to be the most common behaviour across the ecosystem and
there's a specific test for it I expected that this was an oversight in
the spec.
@nblumhardt
Copy link
Contributor

Thanks for this, it's good to try to nail this down.

Serilog (where the majority of these tests came from :-)) originally intended to mirror the behavior of .NET's format string syntax, where ,0 is an acceptable alignment. I'm not sure why this is called out specifically as an exception.

It'd be interesting to see what the consequences of making this case valid in Serilog might be. I don't think we'd be against falling into line with NLog and .NET format strings there, if there was no added execution time or complexity cost 🤔

@Insomniak47
Copy link
Author

Insomniak47 commented May 14, 2024

Thanks for responding!

Yeah I think the only other one that doesn't seem to jive with the spec from what I'm seeing in the serilog repo is:

APropertyWithValidNameAndInvalidFormatIsParsedAsText because the format grammar is Format ::= [^\}]+ so there shouldn't need to be a carve-out for $. That being said if the difference is a bunch of compute obv not the end of the world

I think it might be good as I was kind of alluding to in messagetemplates/test-cases#5 to have larger/more standard corpus... and ideally a test runner that can kick off a process, input a bunch of test cases into its stdin and evaluate the output from stdout so that we can make it easy to check impls in other langs. I'm still cleaning up my impl, I've been standardizing on two error behaviours and that'll probably be the last step and I can toss it into the test-cases repo.

Thinking something like:
"Bippity boopity: {name}!" T("Bippity boopity: ")H("name")T("!")
for input/ output pairs

@Insomniak47
Copy link
Author

@nblumhardt re:

It'd be interesting to see what the consequences of making this case valid in Serilog might be.

Want me to take a look at this then?

@nblumhardt
Copy link
Contributor

Hi! Sounds great; I can't tell at this point whether it's something we'd end up wanting to change, but some investigation would be really helpful 👍

@Insomniak47
Copy link
Author

I've made the change and benched it in serilog/serilog#2064

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants