This update changes the extension's publisher from "matklad" to
"rust-lang" and moves it to `vscode-extensions.rust-lang.rust-analyzer`,
but keeps `vscode-extensions.matklad.rust-analyzer` for backwards
compatibility. It also bumps the version number from 0.2.xxx to 0.3.xxx,
as described in changelog #129.5:
https://rust-analyzer.github.io/thisweek/2022/05/17/changelog-129-5.html
The release tag was out-of-date even though the extension was updated
regularly. Ideally, the update script might increment it on its own,
like the rust-analyzer update script already does.
Among other things fixes build failure on gcc-10:
ld: CMakeFiles/xsuspender.dir/xsuspender.c.o:(.bss+0x8): multiple definition of
`queued_entries'; CMakeFiles/xsuspender.dir/config.c.o:(.bss+0x8): first defined here
This effectively reduces the size of the runtime closure by ~79%:
$ nix path-info ./result-old -Sh
/nix/store/9ggmj6fmqszfvd0lg2im7qssscql0jac-signald-0.15.0 729.0M
$ nix path-info ./result -Sh
/nix/store/z9bfj547j9fkyl8g0mqb1n108s7zw4w5-signald-0.15.0 155.2M
Similar change as 2f9426ad8312101f4e84bcc4e28860695d28005f: newer Java
versions don't support a "traditional" JRE anymore, but it's possible to
create dedicated runtime environments using `jlink`[1].
[1] https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4Closes#150493
Without the change build failure on upxtream gcc-10 as:
ld: hid-libusb.o:/build/source/util.h:38: multiple definition of
`trace_flag'; main.o:/build/source/util.h:38: first defined here
Adds a distribution id useful for aggregation of crash statistics.
Also creates a NixOS flavor, visible through the About window, that is
also exposed through telemetry data, if enabled.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: brightonCLI.o:/build/bristol-0.60.11/brighton/brightonCLI.c:139: multiple definition of
`event'; brightonMixerMenu.o:/build/bristol-0.60.11/brighton/brightonMixerMenu.c:1182: first defined here
This wrapper is useful independently of pandoc-drawio-filter — it's
useful in any other situation in which somebody might want to use
draw.io diagrams in a build process.
So, make it accessible from the top level to facilitate reuse.
Yuka