Unable to setup on mac

[tonyalaribe]

I have this error while trying to setup tree-sitter haskell on a mac:

Do you have any ideas what I might be doing wrong? I tried updating gcc on mac, but this still happens

[tonyalaribe]

The rest of the error:

[PabloReszczynski]

Same problem! I think it may have to do with clang vs gcc

[maxbrunsfeld]

Yeah, I hit this too. The external scanner currently uses come C++14 features, and I guess the clang version on macOS doesn't support those by default. When the Tree-sitter CLI automatically compiles your parser, it just runs your C++ compiler with the default settings (as opposed to passing -std=c++14 or something like that), so it doesn't work.

It'd be great to make that file a little bit more portable. I'm also open to making the Tree-sitter somehow smarter about passing those flags. It just makes the compilation process a bit more complex if you have to pass C++-specific flags. @tek I'd be curious about your opinion - how important is it that the external scanner makes uses of the latest and greatest C++ features? Would it be he hard to make it compile under C++11 semantics?

[tek]

@maxbrunsfeld not sure, but judging from the errors here it's struggling with some c++11 features (lambdas)

[archseer]

I was able to build on macOS by specifying -std=c++14, however I wasn't able to get it working with the msvc equivalent on Windows (/std:c++14)

  languages\tree-sitter-haskell\src\scanner.cc(1555): error C3861: 'to_string': identifier not found
  languages\tree-sitter-haskell\src\scanner.cc(1556): error C3861: 'to_string': identifier not found
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C3536: 'col': cannot be used before it is initialized
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C2676: binary '+': 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>' does not define this operator or a conversion to a type acceptable to the predefined operator
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C2672: 'operator __surrogate_func': no matching overloaded function found
  exit code: 2

[lunixbochs]

@archseer I think the MSVC errors were just fixed by https://github.com/tree-sitter/tree-sitter-haskell/pull/38

[lunixbochs]

I've been triaging https://github.com/tree-sitter/py-tree-sitter/pull/64 and I have tree-sitter-haskell currently building in py-tree-sitter CI on all of windows/mac/linux with a few different c++ target levels.

You can see which jobs pass from the top 3 actions here to see how passing the c++11, c++14, and c++17 flags affect a ~recent compiler on each OS: https://github.com/tree-sitter/py-tree-sitter/actions?query=branch%3Atest-haskell

I vote for tree-sitter-cli and adjacent projects (such as py-tree-sitter) to standardize on setting the same c++ support level, such as c++14 or c++17, for both MSVC and gcc/clang. That's like /std:c++17 for MSVC and -std=c++17 for gcc/clang.

---

compiler support

You can find compiler support here for c++14 and c++17 Clang support should generally be good. I surveyed a couple of Linux distros:

• RHEL 7 ships gcc 4.8
• RHEL 8 ships gcc 8.x
• Ubuntu 16.04 LTS, which hit EOL in April, ships gcc 5.4
• Ubuntu 18.04 ships GCC 7.4.0.

---

conclusion

GCC 7 supports c++17, so think c++17 is a fairly reasonable target given these constraints. It excludes MSVC 14.0, but on Windows the MSVC version is separate from the OS version anyway so it's hopefully not too burdensome to recommend installing a current compiler there.

Once this changes, I would appreciate tree-sitter-haskell adding Windows/Mac build targets similar to py-tree-sitter, so I can leave tree-sitter-haskell in the py-tree-sitter CI without worrying about haskell breaking the py-tree-sitter build for a specific OS.

[tek]

sounds reasonable!

[ahlinc]

May be it's worth to mention in https://github.com/tree-sitter/tree-sitter/issues/930

[theHamsta]

tree-sitter-haskell requires C++14 due to generic lambdas. But nice that the MSVC error was fixed.

[archseer]

Thanks for the fix @lunixbochs! I still get a failure when cross compiling to aarch64-linux with C++14: https://github.com/helix-editor/helix/runs/2759709239

languages/tree-sitter-haskell/src/scanner.cc:87:28: error: variable 'f' has function type
...
languages/tree-sitter-haskell/src/scanner.cc:808:16: error: variable 'fa' has function type

[lunixbochs]

Is that aarch64-linux-android? https://github.com/rust-embedded/cross#supported-targets lists gcc 4.9. They should update that.

[archseer]

aarch64-unknown-linux-gnu

[lunixbochs]

Ah I didn't see that entry, anyway it's 4.8.2 as well. Looks like they're basing the image on Ubuntu 16.04, which is EOL: https://github.com/rust-embedded/cross/blob/master/docker/Dockerfile.aarch64-unknown-linux-gnu#L1

Even if they want to target an older glibc ABI, they should probably install a newer gcc.

[nkpart]

I have a similar but different problem installing on Mac, running TSInstallSync haskell from neovim. My setup is maybe different to a lot of users though. I'm using the nix-based home-manager tool to manage my user account, details:

Creating temporary directory
Extracting...
Compiling...
src/scanner.cc:2:10: fatal error: 'vector' file not found
#include <vector>
         ^~~~~~~~
1 error generated.
Error during compilation
Failed to execute the following command:
{
  cmd = "cc",
  err = "Error during compilation",
  info = "Compiling...",
  opts = {
    args = { "-o", "parser.so", "-I./src", "src/parser.c", "src/scanner.cc", "-shared", "-Os", "-lstdc++", "-fPIC" },
    cwd = "/Users/nkpart/.local/share/nvim/tree-sitter-haskell"
  }
}```

[lunixbochs]

You're compiling a C++ file (.cc suffix) with a C compiler

[theHamsta]

You're compiling a C++ file (.cc suffix) with a C compiler

Which is how nvim-treesitter installs stuff. We're compiling C and C++ and linking in one go which causes some problems for Haskell because we can't set any C or C++ standard but rely on whatever is the default. cc is either gcc or clang and they usually set the language based on the filetype (except Apple clang is again different from normal clang). @nkpart can you make sure you have a C++ runtime installed libc++ on mac or I guess libstdc++ would maybe also work.

[nkpart]

Thanks, I've done some digging.

As you all might know, nvim-treesitter uses https://github.com/nvim-treesitter/nvim-treesitter/blob/ddc0f1b606472b6a1ab85ee9becfd4877507627d/lua/nvim-treesitter/install.lua#L14 to figure out the compiler to use, and then this https://github.com/nvim-treesitter/nvim-treesitter/blob/ddc0f1b606472b6a1ab85ee9becfd4877507627d/lua/nvim-treesitter/shell_command_selectors.lua#L67-L75 for the argument set.

Overriding either of those things is going to be enough to make the compile work. In my case, I could run CC=clang++ vim, and then nvim-treesitter compiles scanner.cc just fine. (CC=clang still failed.)

[aridgupta]

I have gcc installed on mac. How do I install tree-sitter-haskell? It shows the error as mentioned by this issue.

[theHamsta]

@aridgupta as @nkpart mentioned nvim-treesitter will respect the CC env variable. Set the environment variable CC=gcc or in luarequire"nvim-treesitter.install".compilers = {"gcc"}

[aridgupta]

@theHamsta thank you. However, when I would update tree-sitter in the future, won't this fail again?

[theHamsta]

Not when setting require"nvim-treesitter.install".compilers = {"gcc"} in your init.vim (or lua require"nvim-treesitter.install".compilers = {"gcc"} when using vim script

[farbodsz]

For anyone looking through this thread facing similar issues, I was having the same error message but on Ubuntu rather than Mac:

LSB Version:    core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:    18.04
Codename:   bionic

I tried gcc but interestingly, forcing tree-sitter to use clang instead of gcc fixed the problem:

require'nvim-treesitter.install'.compilers = { "clang" }

[tek]

made a note of it in the readme

[tonyalaribe]

I will close this now. require'nvim-treesitter.install'.compilers = { "gcc" } worked for me. Though I had to do TSInstallSync haskell afterwards. Thanks!

[molleweide]

yo.

I'm just chiming in to say I believe I've tried all of the above but things still don't seem to work. I am personally using macos catalina. This was also a very interesting thread to read as a beginner with tree sitter.

Pretty much all errors I get look like this src/scanner.cc:87:10: error: expected expression return [=](A a) { return f(g(a)); }; and it marks the err at the [=].

This is the last info:

last part of err

``` fatal error: too many errors emitted, stopping now [-ferror-limit=] 2 warnings and 20 errors generated. Error during compilation Failed to execute the following command: { cmd = "gcc", err = "Error during compilation", info = "Compiling...", opts = { args = { "-o", "parser.so", "-I./src", "src/parser.c", "src/scanner.cc", "-shared", "-Os", "-lstdc++", "-fPIC" }, cwd = "/Users/hjalmarjakobsson/.local/share/nvim/tree-sitter-haskell" } } ```

What other places can I look at for problem solving? Is there some other secret place or file?

I am also struggling to understand what C++-14 actually means. Does this mean I am using C++-12?:

╰ clang --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

╰ clang++ --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[chianuo]

I can't get this to work either. I've added require'nvim-treesitter.install'.compilers = { "gcc" } to my nvim config, I've added the CC=gcc environment variable, and I still get that massive error when running TSInstall haskell. No clue what I'm doing wrong.

[chianuo]

@molleweide I solved it for me, maybe you're experiencing a similar issue. Basically, macOS symlinks clang to /usr/bin/gcc, so even if you install gcc from brew install gcc, and do the above configuration, you're still secretly using macOS's clang. Bloody hell, Apple.

I fixed it by linking the real gcc somewhere into my path with higher priority. cd /usr/local/bin && ln -s ./gcc-11 gcc. Now it works.

[tek]

made another note in the readme

[tek]

please share your experience so I can improve the instructions!

[albohlabs]

With the hint from @chianuo it works now. Awesome. 🥳

[molleweide]

it wooooooorks!!! 🥳 thanks @chianuo ❤️

[molleweide]

I just got a new M1 mac and I notice that after following the instructions in the readme again on this new mac with M1 doing this:

ln -sf /usr/local/bin/gcc-11 /usr/local/bin/gcc

then which gcc will still show usr/bin/gcc because it seems that usr/local/bin/gcc-11 doesn't exist on M1 mac. Again, I am not so comfortable with gcc so I am not sure if I explaint this in a bad order.. Could this have something to do with homebrew changing default installer location recently? hmm..

[molleweide]

yes it should be ln -sf /opt/homebrew/bin/gcc-11 /usr/local/bin/gcc on Macos with latest version of homebrew.

I submitted a PR with this.

[bimalgaudel]

I was able to build on macOS by specifying -std=c++14

@archseer Could you tell how you specified `-std`?

[kentkwu]

Here's what worked for me, on an M1 mac:

brew install gcc

At this point gcc-11 should be here:

ls /opt/homebrew/bin/ | grep gcc
...
gcc-11
...

And then just explicitly pass in gcc-11 to install.lua

require'nvim-treesitter.install'.compilers = { "gcc-11" }

This way you don't have to mess around with symlinks in /usr/local or changing the path priority.