pchickey commented on Issue #2730:
I approve these changes in
cranelift-module
. I'm not a maintainer ofcranelift-codegen
so I will defer overall approval to someone else - @cfallin maybe?
cfallin commented on Issue #2730:
It's somewhat surprising to me that changes in error-printing code would give such a large speedup in compile times. It's always welcome, of course, when speedups come -- but @bjorn3, do you have any sense of why this happens? I ask because it could be a symptom of something weirder going on behind the scenes -- for example, are we throwing a bunch of errors and doing work to capture backtraces but then silencing them somehow?
All other things being equal, the auto-derived error handling is kind of nice, but I won't fight too hard for it if we win by doing something lighter-weight.
pchickey commented on Issue #2730:
I believe, because
thiserror
is a proc macro that depends on the usual stack ofsyn
and friends, that compiling those dependencies is the tentpole in embeddings which otherwise don't use proc macros.
pchickey edited a comment on Issue #2730:
I believe, because
thiserror
is a proc macro that depends on the usual stack ofsyn
and friends, that compiling those dependencies is the tentpole in embeddings which otherwise don't use proc macros. So, we don't see this in wasmtime or other big applications, but I imagine that cg_clif is very careful about deps.
pchickey edited a comment on Issue #2730:
I believe, because
thiserror
is a proc macro that depends on the usual stack ofsyn
and friends, that compiling those dependencies is the tentpole in embeddings which otherwise don't use proc macros. So, we don't see this in wasmtime or other big applications where we use that family or crates in several contexts, but I imagine that cg_clif is very careful about deps.
cfallin commented on Issue #2730:
Ah -- to clarify, @bjorn3, you mean the compile time of cg_clif, not the time that cg_clif takes to compile code?
(I was assuming the latter, and thus was quite confused about the impact of error-path code on the happy path!)
pchickey edited a comment on Issue #2730:
I believe, because
thiserror
is a proc macro that depends on the usual stack ofsyn
and friends, that compiling those dependencies is the tentpole in embeddings which otherwise don't use proc macros. So, we don't see this in wasmtime or other big applications where we use that family of crates in several contexts, but I imagine that cg_clif is very careful about deps.
bjorn3 commented on Issue #2730:
Ah -- to clarify, @bjorn3, you mean the compile time of cg_clif, not the time that cg_clif takes to compile code?
Correct, I mean the time it takes to compile cg_clif itself. Sorry for the confusion.
but I imagine that cg_clif is very careful about deps.
Indeed. I try to avoid dependencies where possible and even use dependencies from the rustc-dev rustup component instead of crates.io where possible.
pchickey commented on Issue #2730:
Would you mind leaving a comment above the Display & Error impls that these are written by hand to avoid pulling in the
thiserror
dep? That may help anyone who sees them and gets the clever idea that they can be replaced by a macro.
bjorn3 commented on Issue #2730:
Done
bjorn3 commented on Issue #2730:
Rebased
Last updated: Dec 23 2024 at 12:05 UTC