You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following demonstrates a parser ambiguity that I think should throw a ParseError similar to how 1.+1 throws an error:
julia> x! = y -> y[1] =1#1 (generic function with 1 method)
julia> x! ==nothingfalse
julia> x!==nothing
ERROR: UndefVarError:`x` not defined
Stacktrace:
[1] top-level scope
@ REPL[4]:1
julia>versioninfo()
Julia Version 1.10.4
Commit 48d4fd48430 (2024-06-0410:41 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU:32×13th Gen Intel(R) Core(TM) i9-13900HX
WORD_SIZE:64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
Threads:32 default, 0 interactive, 16 GC (on 32 virtual cores)
Environment:
JULIA_NUM_THREADS =32
JULIA_PKG_USE_CLI_GIT =true
In particular, does x!==nothing mean x! == nothing or x !== nothing? The parser silently assumes the latter. I personally always include whitespace, thus circumventing the issue, but I ran across a line of code in NonlinearSolve.jl that does not have whitespace, and so I was surprised the syntax was allowed!
The text was updated successfully, but these errors were encountered:
Yes, the tokenizer assumes != should always be parsed as a token if it's present, taking precedence over a ! on the end of an identifier.
I'm not sure x!=1 should be an error (and it would be breaking to make it one - probably relatively high on the breaking things scale if I had to guess).
I personally agree it's not great style, but I'm not even sure this should be a warning - I'm somewhat inclined to say this belongs in a linter (and code formatting tools) rather than in the parser itself.
The following demonstrates a parser ambiguity that I think should throw a
ParseError
similar to how1.+1
throws an error:In particular, does
x!==nothing
meanx! == nothing
orx !== nothing
? The parser silently assumes the latter. I personally always include whitespace, thus circumventing the issue, but I ran across a line of code in NonlinearSolve.jl that does not have whitespace, and so I was surprised the syntax was allowed!The text was updated successfully, but these errors were encountered: