Hi Willy, > On 3 Feb 2024, at 12:48, Willy Tarreau <w...@1wt.eu> wrote:
> in fact we could check for >> the presence of "and" or "or" on a line, or some other suspicious >> constructs Another approach might be to optionally enforce quotes around strings. While it’d be a breaking change and sounds a bit difficult to offer as a flag, it avoids a lot of the current traps I think. Though I can imagine that many wouldn’t like that (hence my pointing out to a flag or something). Essentially, the current state of things reminds me a bit of some of the error-prone-ness of YAML in that regard (implicit strings). Similarly I can never remember the cases where it’s string, or "string", or str(string), or if quoting a string will maybe include the quotes in the actual value, and which ones are equivalent > Well, this one was took just about the time needed for coffee to start to > make its effect :-) > > How about this: […] > > It gives me no warning but triggers many diag warnings: > > $ ./haproxy -c -f diag.cfg > $ ./haproxy -dD -c -f diag.cfg > [NOTICE] (23315) : haproxy version is 3.0-dev2-d480b7-58 > [NOTICE] (23315) : path to executable is ./haproxy > [DIAG] (23315) : config : parsing [diag.cfg:15] : pattern '//' looks > like a failed attempt at commenting an end of line > [DIAG] (23315) : config : parsing [diag.cfg:16] : pattern 'and' looks > like a failed attempt at using an operator inside a pattern list > […] That already sounds very helpful. I haven’t checked locally but adding an option similar to zero-warning for diagnostics warnings could be nice on top of it; depends on how many FPs happen in practice Tristan
