Kind of operator <: is wrong in GreenNode

[bellon-tiobe]

As you can see in the screen clip above, the kind for the token corresponding to the operator :: is K"::", but the situation for operator <: is not analogous: the node has kind K"Identifier" instead.

Is this intended, or a bug?

[bellon-tiobe]

The case shown above is for infix <:. The situation is better when it is the prefix case for that same operator:

[pfitzseb]

Can't repro this:

julia> JS.parse(JS.GreenNode, "function BadFunName(x::T) where T<:Any end")
     1:42     │[function]
     1:8      │  function
     9:9      │  Whitespace
    10:38     │  [where]
    10:25     │    [call]
    10:19     │      Identifier         ✔
    20:20     │      (
    21:24     │      [::]
    21:21     │        Identifier       ✔
    22:23     │        ::
    24:24     │        Identifier       ✔
    25:25     │      )
    26:26     │    Whitespace
    27:31     │    where
    32:32     │    Whitespace
    33:38     │    [<:]
    33:33     │      Identifier         ✔
    34:35     │      <:
    36:38     │      Identifier         ✔
    39:39     │  [block]
    39:39     │    Whitespace
    40:42     │  end

What's the actual code that reproduces the issue? Also, what version of JuliaSyntax is this on?

[bellon-tiobe]

The only relevant difference I can see is the return x:

julia> JS.parsestmt(JS.GreenNode, "function BadFunName(x::T) where T<:Any return x end")
     1:51     │[function]
     1:8      │  function
     9:9      │  Whitespace
    10:38     │  [where]
    10:25     │    [call]
    10:19     │      Identifier         ✔
    20:20     │      (
    21:24     │      [::]
    21:21     │        Identifier       ✔
    22:23     │        ::
    24:24     │        Identifier       ✔
    25:25     │      )
    26:26     │    Whitespace
    27:31     │    where
    32:32     │    Whitespace
    33:38     │    [<:]
    33:33     │      Identifier         ✔
    34:35     │      Identifier
    36:38     │      Identifier         ✔
    39:47     │  [block]
    39:39     │    Whitespace
    40:47     │    [return]
    40:45     │      return
    46:46     │      Whitespace
    47:47     │      Identifier         ✔
    48:48     │  Whitespace
    49:51     │  end


julia> versioninfo()
Julia Version 1.11.5
Commit 760b2e5b73 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 12 × 13th Gen Intel(R) Core(TM) i7-1355U
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, goldmont)
Threads: 1 default, 0 interactive, 1 GC (on 12 virtual cores)

[pfitzseb]

Very weird -- we're on the same commit and getting different results:

julia> versioninfo()
Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, skylake)
Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)

julia> JS.parsestmt(JS.GreenNode, "function BadFunName(x::T) where T<:Any return x end")
     1:51     │[function]
     1:8      │  function
     9:9      │  Whitespace
    10:38     │  [where]
    10:25     │    [call]
    10:19     │      Identifier         ✔
    20:20     │      (
    21:24     │      [::]
    21:21     │        Identifier       ✔
    22:23     │        ::
    24:24     │        Identifier       ✔
    25:25     │      )
    26:26     │    Whitespace
    27:31     │    where
    32:32     │    Whitespace
    33:38     │    [<:]
    33:33     │      Identifier         ✔
    34:35     │      <:
    36:38     │      Identifier         ✔
    39:47     │  [block]
    39:39     │    Whitespace
    40:47     │    [return]
    40:45     │      return
    46:46     │      Whitespace
    47:47     │      Identifier         ✔
    48:48     │  Whitespace
    49:51     │  end

The only difference seems to be the OS, but I don't see how JuliaSyntax could behave differently on Windows, especially since there are no newlines in the code...

[bellon-tiobe]

I work mostly on the WSL, but I get the same result:

julia> JS.parsestmt(JS.GreenNode, "function BadFunName(x::T) where T<:Any return x end")
     1:51     │[function]
     1:8      │  function
     9:9      │  Whitespace
    10:38     │  [where]
    10:25     │    [call]
    10:19     │      Identifier         ✔
    20:20     │      (
    21:24     │      [::]
    21:21     │        Identifier       ✔
    22:23     │        ::
    24:24     │        Identifier       ✔
    25:25     │      )
    26:26     │    Whitespace
    27:31     │    where
    32:32     │    Whitespace
    33:38     │    [<:]
    33:33     │      Identifier         ✔
    34:35     │      Identifier
    36:38     │      Identifier         ✔
    39:47     │  [block]
    39:39     │    Whitespace
    40:47     │    [return]
    40:45     │      return
    46:46     │      Whitespace
    47:47     │      Identifier         ✔
    48:48     │  Whitespace
    49:51     │  end

julia> versioninfo()
Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 12 × 13th Gen Intel(R) Core(TM) i7-1355U
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, goldmont)
Threads: 1 default, 0 interactive, 1 GC (on 12 virtual cores)

[bellon-tiobe]

The only difference I see between our platforms (when I use WSL) is the code name after ORCJIT, in the detail after the LibLLVM version. Could that be relevant in any way?

[KristofferC]

This changed with #523, no? You two are on the same julia commit but what is interesting is what JuliaSyntax you are on?

[bellon-tiobe]

You two are on the same julia commit but what is interesting is what JuliaSyntax you are on?

What do you mean with "what JuliaSyntax"? We are using the same kind of tree in the parsing, if that is what you refer to...

This changed with #523, no?

If a lot of operators are going to have theirs kinds replaced with K"Identifier", that will be a big hindrance for my efforts, since I know no way to "untokenize" a GreenNode node. Suggestions are more than welcomed.

[KristofferC]

What do you mean with "what JuliaSyntax"?

I meant what JuliaSyntax version.

[bellon-tiobe]

I meant what JuliaSyntax version.

Ah, this, right?

(@v1.11) pkg> status
Status `~/.julia/environments/v1.11/Project.toml`
  [70703baa] JuliaSyntax v1.0.2

[bellon-tiobe]

From my Manifest.toml:

[[deps.JuliaSyntax]]
git-tree-sha1 = "0d4b3dab95018bcf3925204475693d9f09dc45b8"
uuid = "70703baa-626e-46a2-a12c-08ffd08c73b4"
version = "1.0.2"

[KristofferC]

From #523 it seems @pfitzseb is on the older JS version.

[bellon-tiobe]

Aha, so this is "the new normal"... Thanks, Kristoffer.

Given that, how can I find out which operator is there, considering it is a GreenNode? Only by finding out its exact position in the input source?

[Keno]

Given that, how can I find out which operator is there, considering it is a GreenNode? Only by finding out its exact position in the input source?

Yes, the green tree always needs to be read in conjuction with the original source. It's an overlay tree.

Closing issue as intended behavior.