Fix YamlDecoder and NaN tag

[sideeffffect]

https://yaml.org/spec/1.2.2/#1032-tag-resolution

https://scastie.scala-lang.org/9DqmGdYWQwWA9OUmjqjbCg

Relates to

• Decoding as[Any] processing numbers with 32b precision only #314
• fix precision loss when parsing floats via YamlDecoder[Any] #322

/cc @lbialy @OndrejSpanel

[lbialy]

Haha, my first draft for NaN/Inf parsing used regex too and after Tomek's nitpick I decided to simplify at the cost of precision with endsWith. It's also a bit faster than regex I think. Is this a problem you have encountered in a real scenario (the -XXXInf) or are you just fixing the possible edge case? I mean, I thought about it for a minute and decided it's rather improbable that user would expect the field to be a Float/Double and it would contain a string ending with Inf by chance.

Proper perf-optimized impl would not use regex so it's a question whether we want to even take perf into consideration.

[sideeffffect]

If you attempt to parse a string "Reinf" as Float and succeed, then that's just a bug. There's no way around it.

I don't mind if you optimize it further. I'm sure people, me included, would welcome that. (Generally speaking, optimizations should go hand in hand with benchmark, to show that they actually are optimizations.)

But first it needs to be correct.

Is this a problem you have encountered in a real scenario (the -XXXInf) or are you just fixing the possible edge case?

Fortunately I didn't stumble upon this bug in production. I was just reading the code and it figuratively jumped at me.

[lbialy]

@tgodzik we're back to regex matching, but this impl is cleaner than mine, I like it

[lbialy]

Btw this Any parsing is correct but very very slow.

[sideeffffect]

Btw this Any parsing is correct but very very slow.

Do you have some numbers or any hint what actually is the bottleneck? Is it really the regex matching? That is something which won't be too difficult to fix. Maybe I could have a look at it myself if/when I have some time...

[sideeffffect]

I'd be happy to ditch the regexes and do "manual" comparisons, if it helps the PR to get merged.
(I just don't have any benchmarks that could show how much it improves performance.)

[lbialy]

No need, it's fine, like I said, I went the same way on the original PR before review. Performance would have to be considered separately with a serious amount of pondering whether it's actually relevant in a yaml library. Does anyone actually parse or print yaml at scale?