Open saethlin opened 3 years ago
Hi there,
I for sure do not want the panics, but I would certainly welcome ideas about strategies that can improve compile times.
I'm also not convinced this strategy even produces useful errors, because its error messages are rendered useless by helper functions, such as from_iter and split_into_num.
Could you say a bit more about this, or maybe provide an example? I have to admit, the error messages mostly designed for me, so if I receive a bug report, I can pretty quickly see where the parsing problem is. But many of them haven't actually been triggered (and so there could easily be some poorly constructed error messages).
Here's an example, though, that I came up with quickly (I just added this to the bottom of net.rs):
#[test]
fn test_error_msg() {
let _ = DeviceStatus::from_str("eth0 -1").unwrap();
}
And the resulting error message is:
---- net::tests::test_error_msg stdout ----
thread 'net::tests::test_error_msg' panicked at 'called `Result::unwrap()` on an `Err` value: InternalError(bug at src/net.rs:573 (please report this procfs bug)
Internal Unwrap Error: Internal error: bug at src/lib.rs:260 (please report this procfs bug)
Internal Unwrap Error: Failed to convert)', src/net.rs:727:51
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The useful pointer for me is the bug at src/net.rs:573
part. I admit the pointers to lib.rs:260
and net.rs:727
are pretty useless, though.
I guess one possibility would be to have this type of error message (capturing the exact line number) only in debug builds, not release builds, but maybe that doesn't really get rid of the pain.
In a decently large project with 255 dependencies, this crate ranks 6th by compile time in a debug build:
It looks like approximately 40% of this crate's build time was introduced by the strategy employed in https://github.com/eminence/procfs/pull/48. As far as I can understand, the idea there was to nest macros so that the value produced
line!()
is relevant to the error. The problem is that this strategy causes this crate to balloon after macro expansion. If I runcargo llvm-lines | head
in this crate, I get this:which is quite unusual, and points squarely at the large amount of code that (for example)
from_str!
expands into.I'm also not convinced this strategy even produces useful errors, because its error messages are rendered useless by helper functions, such as
from_iter
andsplit_into_num
.Are you interested in a PR that doesn't introduce the panics back, but which tries to do something about the compile time regression from #48, even if it removes some of the file+line information?