miniblog.
← Back to all posts
Dec 28, 2020 at 06:34
1
It's well known that certain compiler optimisations matter way more than others (e.g. inlining). Is there a similar principle for linters? I find red squiggles under unused/undefined variables the single most useful check.
Likes
~vidak :emacs:
Related Posts
Jul 29, 2023 at 17:33
Go has a wonderful, accessible discussion of how it does inlining today, the downsides, and the plans for 1.22:
Go 1.22 inlining overhaul
Go 1.22 inlining overhaul , with contributions from , , , and Last update: The Go compiler’s inliner has never been particularly good. It wasn’t until Go 1.12, released in 2019, that the Go compiler supported inlining more than leaf functions, and we’ve slowly chipped away at more limita...
Aug 3, 2021 at 03:40
On the nuances of Rust inlining, crate boundaries, and what gets inlined by default:
https://matklad.github.io/2021/07/09/inline-in-rust.html
Nov 6, 2018 at 23:45
Mid stack inlining in Go:
https://go.googlesource.com/proposal/+/master/design/19348-midstack-inlining.md
(Interesting implementation details: the inliner is AST based, how to preserve existing stack reflection APIs, and how to show good tracebacks.)
Proposal: Mid-stack inlining in the Go compiler