feat: add haskell highlights

[elianiva]

Since Haskell parser is getting better, I guess it's time to add the highlight query.

Bare in mind that I just started to learn Haskell recently so the highlight group used here might not be accurate, so please give me your suggestions :)

you might want to take a look at/try this @phaazon

[theHamsta]

As I said earlier, whoever wants to add Haskell must fix its build on CI #1080 (if maybe even with a xfail not possible to do it differently). Feel free to rebase on #1080 to ensure that all parsers get installed.

@guibou might also already have highlights

[elianiva]

hmm, the CI still fails

[theHamsta]

@elianiva rebasing on the PR did not fix the breakage. It only makes it apparent. Before Haskell was failing but CI was nevertheless green. I guess Haskell requires C++14 or at least C++11 as a default when you compile without flags. We can't set the standard because we compile C and C++ in one command. You could add a environment variable that Haskell parser is allowed to fail or compile the C and C++ file in a separate command or try to install a newer compiler.

Windows fails on all our builds due to a different reason. nvim.exe installation fails?

[elianiva]

it seems to be a problem with chocolatey server

---

You could add a environment variable that Haskell parser is allowed to fail or compile the C and C++ file in a separate command or try to install a newer compiler.

will try messing around with CI later, thanks for the advice

[theHamsta]

Fixes #1060

[elianiva]

if I want to split c and cpp compilation, how do I check if it's a C file or a C++ file? Is the file extension enough? .c vs .cc or .cpp

[theHamsta]

File extension would be enough. I'm not sure whether we want to add the complexity of a C vs C++ compilation step or just require a recent compiler for Haskell.

emacs-tree-sitter uses tree-sitter CLI to compile all parsers: https://github.com/theHamsta/emacs-tree-sitter/blob/887ad56d5c755d0007905d874e48eeedb2e8a383/langs/tree-sitter-langs-build.el#L227-L241

[elianiva]

I'm not sure whether we want to add the complexity of a C vs C++ compilation step

yeah, I thought so too, it's not worth it for just one language

emacs-tree-sitter uses tree-sitter CLI to compile all parsers

if we do this, then we'd need the users to have tree-sitter-cli right? or do we use it only for the CI?

[theHamsta]

It could be a solution just for Haskell or just for CI. A few parsers for niche languages already require tree-sitter CLI now. I don't know which requirement is stronger a very recent compiler or tree-sitter. Update the compilers could also be a solution for CI

[theHamsta]

https://github.com/tree-sitter/tree-sitter/blob/89e1157a299596f3ce2155ba9fd69d5e2c03d3e6/cli/src/loader.rs#L291-L334

It looks like tree-sitter CLI does not specify a standard for C++. So it will fail, the same way as right now for compilers that don't support C++11/14 out of the box.

[elianiva]

llvm --HEAD should be the latest compiler, correct? that one also failed..

[theHamsta]

But it seems that clang is the system compiler (Apple clang). My clang-13 dev build can install Haskell. Maybe it's also clang-12

[elianiva]

might be related actions/runner-images#257 (comment)

[theHamsta]

Can you try clang-12? The binary may be called like that without --HEAD current LLVM is clang 12

[theHamsta]

Probably, allow failures on Windows for Haskell would be sufficient for now.

[theHamsta]

@elianiva did you remove the ALLOW_INSTALLATION_FAILURE in the workflow file?

GCC seems to accept -x as well. Maybe you can specify c99 and c++14 at the same time with this? Problem seem to be generic lambdas that are a C++14 feature.

[elianiva]

hmm, how is the arguments ordered? I tried this but I got error: invalid argument '-std=c++14' not allowed with 'C'

clang -o parser.so -I./src -x c -std=c99 src/parser.c -x c++ -std=c++14 src/scanner.cc -shared -Os -lstdc++ -fPIC

[theHamsta]

It's probably not possible. When you use clang-12 instead of clang on Mac it should work.

[theHamsta]

clang-12... seems not to work. Even though it works locally for me

[theHamsta]

There seems to be no easy fix for this. Do we want to merge this this despite the C++14 problems?

[theHamsta]

@Congee I meant this PR. The readme reflects the maintenance of the parser for nvim-treesitter not whether the project itself is active.

[Congee]

@theHamsta Below are my results of testing this PR. I don't know how you would define quality. To me, it "works" and needs to be polished further as highlighting is missing on some lines.

First one with nvim-treesitter highlight

Second one after :TSDisableAll highlight

Code is copied from https://rosettacode.org/wiki/Universal_Turing_machine#Haskell

[elianiva]

are you sure you're using the latest parser? Works fine for me.
FWIW there's an older version of the parser that breaks when it encounters a multiline code without an empty line in between.

[Congee]

@elianiva How do I verify that? According to the lockfile.json, 2e33ffa3313830faa325fe25ebc3769896b3a68b is the latest commit hash from https://github.com/tree-sitter/tree-sitter-haskell

[elianiva]

yes, that is the latest hash. Have you tried running :TSUpdate?

[Congee]

Yep, I did :TSUpdate before posting screenshots. :TSUpdate haskell says [nvim-treesitter] [1/1] Treesitter parser for haskell has been installed and :TSUpdate says All parsers are up-to-date! but nothing changes to highlighting.

[elianiva]

hmm, something funny is going on. I'm not sure what causes that..
could you install nvim-treesitter/playground and check if that Tape is a constructor node?

[Congee]

Just played with nvim-treesitter/playground. The side bar shows infor about the first two lines of "move Stay" and "move MLeft". Information of the third line "move MRright" is completely missing. What makes it funnier is I got a core dump when trying to quite nvim.

Maybe cosmic ray flipped a bit on my hardware. I dunno. 🤷

Anyways, I have no problem with PR and am willing to help test more if you need to.

[vigoux]

Wow do you have some repro steps for this core dump? I thought we fixed it a while ago...

[Congee]

@vigoux I am unable to reproduce it but can give you some pointers from the core dump.

~/nix/packages$ coredumpctl debug 8265
           PID: 8265 (nvim)
           UID: 1000 (cwu)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Tue 2021-05-18 20:41:13 EDT (20h ago)
  Command Line: /home/cwu/.nix-profile/bin/vi --cmd let g:node_host_prog='/nix/store/gdqf8kxvi4lj4f2dhla9gk4aq4c76w2r-neovim-master/bin/nvim-node' --cmd let g:python_host_prog='/nix/store/gdqf8kxvi4lj4f2dhla9gk4aq4c76w2r-neovim-master/bin/nvim-python' --cmd let g:python3_host_prog='/nix/store/gdqf8kxvi4lj4f2dhla9gk4aq4c76w2r-neovim-master/bin/nvim-python3' --cmd let g:ruby_host_prog='/nix/store/gdqf8kxvi4lj4f2dhla9gk4aq4c76w2r-neovim-master/bin/nvim-ruby' app/Main.hs
    Executable: /nix/store/6h5ihva8d6icb6chj6gib6a2d3h15wqq-neovim-unwrapped-master/bin/nvim
 Control Group: /user.slice/user-1000.slice/user@1000.service/gnome-launched-Alacritty.desktop-1390.scope
          Unit: user@1000.service
     User Unit: gnome-launched-Alacritty.desktop-1390.scope
         Slice: user-1000.slice
     Owner UID: 1000 (cwu)
       Boot ID: bbe7c36656de4900832218a2df8f9300
    Machine ID: fdd44215ffce4877b5ee94a14dbb6384
      Hostname: nixos
       Storage: /var/lib/systemd/coredump/core.nvim.1000.bbe7c36656de4900832218a2df8f9300.8265.1621384873000000.lz4
       Message: Process 8265 (nvim) of user 1000 dumped core.

GNU gdb (GDB) 10.1
Reading symbols from /nix/store/6h5ihva8d6icb6chj6gib6a2d3h15wqq-neovim-unwrapped-master/bin/nvim...
(No debugging symbols found in /nix/store/6h5ihva8d6icb6chj6gib6a2d3h15wqq-neovim-unwrapped-master/bin/nvim)

warning: Can't open file /run/nscd/dbYcZQWf (deleted) during file-backed mapping note processing
[New LWP 8265]
[New LWP 8266]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/v8q6nxyppy1myi3rxni2080bv8s9jxiy-glibc-2.32-40/lib/libthread_db.so.1".
Core was generated by `/home/cwu/.nix-profile/bin/vi --cmd let g:node_host_prog='/nix/store/gdqf8kxvi4'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000006e3d7d in win_findbuf ()
[Current thread is 1 (Thread 0x7f25e6bcc740 (LWP 8265))]

(gdb) info frame
Stack level 0, frame at 0x7ffcd1394370:
 rip = 0x6e3d7d in win_findbuf; saved rip = 0x506455
 called by frame at 0x7ffcd13945b0
 Arglist at 0x7ffcd1394318, args:
 Locals at 0x7ffcd1394318, Previous frame's sp is 0x7ffcd1394370
 Saved registers:
  rbx at 0x7ffcd1394338, rbp at 0x7ffcd1394340, r12 at 0x7ffcd1394348, r13 at 0x7ffcd1394350,
  r14 at 0x7ffcd1394358, r15 at 0x7ffcd1394360, rip at 0x7ffcd1394368
(gdb) bt
#0  0x00000000006e3d7d in win_findbuf ()
#1  0x0000000000506455 in call_func ()
#2  0x000000000058aff4 in nlua_call ()
#3  0x00007f25e6db69d5 in ?? ()
   from /nix/store/q70jl8py9bxvd8c7inkfjb1wscx7fppv-luajit-2.1.0-2020-12-28/lib/libluajit-5.1.so.2
#4  0x00007f25e6e0c159 in lua_pcall ()
   from /nix/store/q70jl8py9bxvd8c7inkfjb1wscx7fppv-luajit-2.1.0-2020-12-28/lib/libluajit-5.1.so.2
#5  0x000000000058fd82 in nlua_call_ref ()
#6  0x000000000048efc4 in buf_updates_unload ()
#7  0x0000000000484d87 in close_buffer ()
#8  0x0000000000486db4 in set_curbuf ()
#9  0x000000000051ea9a in check_changed_any ()
#10 0x0000000000531057 in ex_quit.lto_priv ()
#11 0x000000000052498f in do_one_cmd ()
#12 0x0000000000526902 in do_cmdline ()
#13 0x00000000005d3db3 in nv_colon.lto_priv ()
#14 0x00000000005ce81c in normal_execute.lto_priv ()
#15 0x000000000068785c in state_enter ()
#16 0x00000000005ca22b in normal_enter ()
#17 0x0000000000448a03 in main ()
(gdb) x/4w $rbx
0x3114cc0:      1004    0       0       0
(gdb) x/4w $rbp
0x280f6d0:      1       0       0       0
(gdb) x/4w 0x7ffcd1394318
0x7ffcd1394318: 7224640 0       -719093552      32549
(gdb) quit

[theHamsta]

tree-sitter/tree-sitter-haskell#38 should have fixed the build for MSVC. Only Apple Clang is still failing

[expipiplus1]

How does this relate to this: tree-sitter/tree-sitter-haskell#35

I had no luck getting treesitter-haskell working in nvim.

[theHamsta]

@expipiplus1 you need a compiler that uses C++14 as a default which should be the for all most recent versions of every compiler except for Apple clang. We're right now compiling C and C++ in a single command which does not cause problems since all other parsers only require C++11 except for the Haskell parser which needs C++14 for generic lambdas. When you're using a single command invokation for mixed languages you cannot specify C++ standard.

[expipiplus1]

Thanks, but I didn't have any trouble compiling it, rather as I mention in the linked issue it just doesn't seem to function inside nvim.

…

On Tue, 8 Jun 2021, 12:47 am Stephan Seitz, ***@***.***> wrote: @expipiplus1 <https://github.com/expipiplus1> you need a compiler that uses C++14 as a default which should be the for all most recent versions of every compiler except for Apple clang. We're right now compiling C and C++ in a single command which does not cause problems since all other parsers only require C++11 except for the Haskell parser which needs C++14 for generic lambdas. When you're using a single command invokation for mixed languages you cannot specify C++ standard. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRJXB67EGTUSZ6YJBB46LTRTZYLANCNFSM43J6MYYQ> .

[theHamsta]

Oh, sorry @expipiplus1 I confused two different issue. I'm also experiencing the problem on my machine. Maybe the scanner is keeping some state in the wrong way. Have you tried to compile the tree-sitter's wasm playground for tree-sitter-haskell? Would be interesting whether the editing behavior is the same

[elianiva]

I've merged @farbodsz query

[SanchayanMaity]

FWIW, seems to work without problems here.

[theHamsta]

1+ for merging. Apple Clang on MacOS is now the only platform failing and I don't see a solution that doesn't involve a complication of the compilation workflow

[SanchayanMaity]

Anything blocking this from getting merged?

[theHamsta]

No😅 just wanted to clarify that Haskell CI is still set to expected to fail which is ok for me.