New point release (for Apple Silicon homebrew)

[clason]

Would you consider cutting a 2.2.1 release in the near future? There are ~60 commits since 2.2.0, and a new release would help homebrew support texlab with Rust 1.49 on Apple Silicon (Homebrew/homebrew-core#68301).

(Or if a 3.0.0 release is upcoming, even better :) There's also LSP spec 3.16 out now, but I don't think that has much impact on texlab?)

[pfoerster]

Would you consider cutting a 2.2.1 release in the near future?

The 2.2.1 release is on the way 🚀 .

(Or if a 3.0.0 release is upcoming, even better :)

I am a bit busy right now but 3.0.0 is still being worked on. In particular, I ditched the handwritten LaTeX parser in favor of tree-sitter (the handwritten parser became too hard to maintain in the long term so I put a bit of work into optimizing tree-sitter). A lot of the features became much more easier to implement however I am not done with updating all the features yet. I will share the grammars once I consider them stable enough.

[clason]

No hurry, that's excellent news! Very excited :)

[clason]

Homebrew bump PR is up, but CI fails on ARM with

The following warnings were emitted during compilation:

warning: error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch

error: failed to run custom build command for `bibutils-sys v0.1.0`

Caused by:
  process didn't exit successfully: `/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-6c8a03930460af41/build-script-build` (exit code: 1)
  --- stdout
  TARGET = Some("aarch64-apple-darwin")
  OPT_LEVEL = Some("3")
  HOST = Some("aarch64-apple-darwin")
  CC_aarch64-apple-darwin = None
  CC_aarch64_apple_darwin = None
  HOST_CC = None
  CC = Some("clang")
  CFLAGS_aarch64-apple-darwin = None
  CFLAGS_aarch64_apple_darwin = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("false")
  CC_aarch64-apple-darwin = None
  CC_aarch64_apple_darwin = None
  HOST_CC = None
  CC = Some("clang")
  CFLAGS_aarch64-apple-darwin = None
  CFLAGS_aarch64_apple_darwin = None
  HOST_CFLAGS = None
  CFLAGS = None
  CRATE_CC_NO_DEFAULTS = None
  running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-apple-darwin" "-D_CRT_SECURE_NO_WARNINGS" "-o" "/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-36b8a64a56b3af97/out/vendor/lib/adsout.o" "-c" "vendor/lib/adsout.c"
  cargo:warning=error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch
  exit code: 1

  --- stderr


  error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=aarch64-apple-darwin" "-D_CRT_SECURE_NO_WARNINGS" "-o" "/private/tmp/texlab-20210106-45896-1kclljy/texlab-2.2.1/target/release/build/bibutils-sys-36b8a64a56b3af97/out/vendor/lib/adsout.o" "-c" "vendor/lib/adsout.c" with args "clang" did not execute successfully (status code exit code: 1).

(apparently -target isn't supported/enough anymore?)

[carlocab]

CI logs: https://github.com/Homebrew/homebrew-core/runs/1658878667

[carlocab]

From this run: https://github.com/Homebrew/homebrew-core/pull/68404/checks?check_run_id=1658968613

   Compiling string_cache_codegen v0.5.1
error[E0432]: unresolved import `syn::export`
 --> crates/jsonrpc_derive/src/lib.rs:7:11
  |
7 | use syn::{export::TokenStream2, *};
  |           ^^^^^^ could not find `export` in `syn`

error: aborting due to previous error

Sounds like it could be related to wasmerio/wasmer#1986 (comment).

[richiksc]

I've looked at the failure output for the 11-arm Homebrew build. The build script is calling clang with the Rust target triple of aarch64-apple-darwin. I tried compiling a simple "Hello, World" C program locally using clang --target=aarch64-apple-darwin hello.c, and sure enough, I got the same error:

% clang --target=aarch64-apple-darwin hello.c
error: unknown target triple 'unknown-apple-macosx11.0.0', please use -triple or -arch

The Clang target triple for Apple Silicon is arm64-apple-darwin, and you can verify this by running clang --version.

When compiled with --target-arm64-apple-darwin, sure enough, it works fine.

% clang --target=arm64-apple-darwin hello.c
% ./a.out
Hello, world!

I'll open a PR to fix this.

[richiksc]

The issue between aarch64 and arm64 in clang was fixed in a recent version of the cc crate. I've opened a PR (latex-lsp/bibutils-sys#4) and checked in a Cargo.lock file. Once that gets a new point release, the version of bibutils-sys used by texlab will also have to be bumped.

[richiksc]

Thanks @pfoerster for merging my PR latex-lsp/bibutils-sys#4!. I've opened a new PR on this repo that bumps the bibutils-sys version, and I've confirmed that it builds succesfully locally on my ARM Mac.

#346

[pfoerster]

The issue with syn should be fixed now. If there is anything else, that needs to be done, please let me know.
Thanks again @richiksc for the pull requests.

[richiksc]

@pfoerster syn::{export::TokenStream2} is still imported in crates/jsonrpc_derive/src/lib.rs, which is what threw the error with syn we were seeing previously. However, it shouldn't affect us as long as we build with --locked and the syn version is never updated above 1.0.57. However, for a 'real' long-term fix, it looks like syn (looking at the syn source code) just re-exports proc_macro2::TokenStream as TokenStream2, so everything can probably be moved to TokenStream. However, I'm not very familiar with procedural macros or syn, so take my words with a grain of salt.

The PRs didn't fix the syn issue, but they fixed the cc issue handling the target aarch64 to arm64. We should be able to build successfully on Homebrew if a new 2.2.2 release is published.

Thanks for all your help @pfoerster!

[pfoerster]

syn::{export::TokenStream2} is still imported in crates/jsonrpc_derive/src/lib.rs, which is what threw the error with syn we were seeing previously. However, it shouldn't affect us as long as we build with --locked and the syn version is never updated above 1.0.57. However, for a 'real' long-term fix, it looks like syn (looking at the syn source code) just re-exports proc_macro2::TokenStream as TokenStream2, so everything can probably be moved to TokenStream. However, I'm not very familiar with procedural macros or syn, so take my words with a grain of salt.

I just saw that I forgot to push the commit. 14099ff should be the fix.

[clason]

Great! If you cut a new point release, I'll update the homebrew PR!

[clason]

ARM bottle built successfully \o/

Thanks @richiksc !

[richiksc]

/sparkle @pfoerster for quick responses and for fixing syn

[clason]

...aaand it's merged. homebrew should now install native texlab on ARM.

[carlocab]

Thanks for the help all! If any of you still have time to help chip away at some of the other formulae at Homebrew/homebrew-core#68301, that'd be much appreciated.

[JohnDDuncanIII]

I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the macOS ARM (M1) architecture in https://github.com/latex-lsp/texlab/releases? I don't have the rust toolchain installed and prefer manually putting static binaries in /opt/bin/ rather than using homebrew.

No worries if not (i've been meaning to install rust anyway), but I thought that it wouldn't hurt to ask.

I'm hoping that this will fix the errors that I'm running into trying to run texlab with Sublime Text 3.

---

In Sublime Text 3 3.2.2 running through Rosetta on macOS 11.3.1, after adding

{
	"clients":
	{
		"gopls":
		{
			"enabled": true
		},
		"texlab":
		{
			"command":
			[
				"/opt/bin/texlab -vvvv --log-file ~/Desktop/texlab.log"
			],
			"enabled": true,
			"languages":
			[
				{
					"document_selector": "text.tex.latex",
					"languageId": "latex"
				},
				{
					"document_selector": "text.bibtex",
					"languageId": "bibtex"
				}
			]
		}
	}
}

to ~/Library/Application Support/Sublime Text 3/Packages/User/LSP.sublime-settings, I am unable to get texlab working through LSP for some reason.

texlab shows up in the LSP enable/disable language servers dialog, but it seems like the language server never initializes since that texlab.log file is never written to the desktop and there is no autocomplete in the cv.tex file.

---

I also tried following

Note: To enable code completions while typing, ensure to have text.tex.latex (for LaTeX files) and/or text.bibtex (for BibTeX files) included in the auto_complete_selector setting in your Preferences.sublime-settings file. For further requirements see the TexLab Docs.

from https://lsp.readthedocs.io/en/latest/#latex. While that enabled the builtin sublime autocomplete, it still did not enable the LSP texlab autocomplete.

[carlocab]

I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the macOS ARM (M1) architecture in https://github.com/latex-lsp/texlab/releases?

I think you need to be running Big Sur to cross-compile to ARM; not sure. If this is correct, then it wouldn't be possible, as GitHub CI is running Catalina.

GitHub CI running Big Sur is in private preview: actions/runner-images#2486 might be a while before it gets rolled out more widely.

[carlocab]

However, if you want a texlab binary compiled natively for ARM:

curl -L -H 'Authorization: Bearer QQ==' https://ghcr.io/v2/homebrew/core/texlab/blobs/sha256:a7ea2815cad10428a20d326eddcb670151939c865074005f0fdfb6961640c35b | tar -x

This will extract a directory called texlab in your current directory. A texlab executable can be found in texlab/3.0.0/bin. Put it wherever you want.

[pfoerster]

I'm not sure how Rust handles cross-compilation, but would it be possible to compile static binaries for the macOS ARM (M1) architecture in https://github.com/latex-lsp/texlab/releases? I don't have the rust toolchain installed and prefer manually putting static binaries in /opt/bin/ rather than using homebrew.

I would like to provide binaries for more platforms including Apple Silicon and BSD but I have never used these platforms so I would need some help for this. I will gladly accept pull requests that extend our CI scripts with builds for other platforms.