transparent attribute

[nrc]

#[transparent] on functions and types, basically means never presented to the user (modulo a flag to turn this off). E.g., would be on the unwrap implementation methods so that that a stack trace doesn't display the noise of the panic and unwrap implementation as the top of the stack trace.

Use on types is to avoid telling the user about things like UnsafeCell which are usually just noise in error messages for users, they should be transparent wrappers.

Used by std libs in Swift.

cc @gankro

[mark-i-m]

I'm curious what impact this would have on debugging. I can see how this would be useful, but I can also imagine wanting to know what the whole stack trace is. Is that what you mean by

modulo a flag to turn this off

[joshtriplett]

To avoid confusion, I'd suggest that we shouldn't hide such functions by default; we should just de-emphasize them, and emphasize the top non-transparent item in the stack. Otherwise, when people learning Rust see a panic, the stack traces might have a lot less didactic value for them.

[mark-i-m]

@joshtriplett This is a good point...

Another idea would be to de-emphasize code in external crates by default. This idea is orthogonal to the original proposal...

[Ixrec]

One of the tools I use at work displays Javascript call stacks with the "uninteresting parts" collapsed into lines like "10 frames omitted from [module name]". Is that the sort of thing you have in mind when you say "deemphasizing"?

[mark-i-m]

This is what I imagined...

Take this stack trace:

thread 'main' panicked at 'Oh no! :O', <anon>:3
stack backtrace:
   1:     0x55b97e91d76a - std::sys::imp::backtrace::tracing::imp::write::h3188f035833a2635
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x55b97e91f69f - std::panicking::default_hook::{{closure}}::h6385b6959a2dd25b
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:349
   3:     0x55b97e91f29e - std::panicking::default_hook::he4f3b61755d7fa95
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:365
   4:     0x55b97e91fa87 - std::panicking::rust_panic_with_hook::hf00b8130f73095ec
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:553
   5:     0x55b97e918833 - std::panicking::begin_panic::haa6e343a5b54e680
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:515
   6:     0x55b97e9189f7 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:3
   7:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
   8:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
   9:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  10:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  11:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  12:     0x55b97e918a40 - rust_out::main::h0c6f2596c7f28a79
                        at /tmp/<anon>:10
  13:     0x55b97e9273aa - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  14:     0x55b97e91ff86 - std::rt::lang_start::h65647f6e36cffdae
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:434
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panic.rs:351
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/rt.rs:57
  15:     0x55b97e918a82 - main
  16:     0x7f8427ac082f - __libc_start_main
  17:     0x55b97e918658 - _start
  18:                0x0 - <unknown>

We might want to "de-emphasize" the stack trace entries in libpanic_unwind and std::panicking... Something maybe like this:

thread 'main' panicked at 'Oh no! :O', <anon>:3
stack backtrace:
   1:     0x55b97e91d76a - std::sys::imp::backtrace::tracing::imp::write::h3188f035833a2635
   2:     0x55b97e91f69f - std::panicking::default_hook::{{closure}}::h6385b6959a2dd25b
   3:     0x55b97e91f29e - std::panicking::default_hook::he4f3b61755d7fa95
   4:     0x55b97e91fa87 - std::panicking::rust_panic_with_hook::hf00b8130f73095ec
   5:     0x55b97e918833 - std::panicking::begin_panic::haa6e343a5b54e680

   6:     0x55b97e9189f7 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:3
   7:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
   8:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
   9:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  10:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  11:     0x55b97e918a14 - rust_out::foo::h30c73b6cab138c93
                        at /tmp/<anon>:5
  12:     0x55b97e918a40 - rust_out::main::h0c6f2596c7f28a79
                        at /tmp/<anon>:10

  13:     0x55b97e9273aa - __rust_maybe_catch_panic
  14:     0x55b97e91ff86 - std::rt::lang_start::h65647f6e36cffdae
  15:     0x55b97e918a82 - main
  16:     0x7f8427ac082f - __libc_start_main
  17:     0x55b97e918658 - _start
  18:                0x0 - <unknown>

[kornelski]

I've implemented something like this once for cleanup of exception stack traces (in a custom error reporting solution for PHP), and I've found that "transparent" is not quite what I wanted.

The problem is that errors fall into two separate categories:

1. it's the caller's fault (e.g. wrong parameters passed in, method called when the object is in a wrong state, etc.)
2. it's implementation's fault (out of bounds, assertions, etc.)

So in case (1) you want the function to be transparent (so the user sees place where they call it and args they pass in), but in (2) you specifically don't want it (as it'd hide the actual error and incorrectly blame the user).

[shepmaster]

How would line numbers in the reported error message work? Right now, panic! uses the line!() and file() macros to grab these. If the panic message says one file (the real location) and the stack trace doesn't include that, it would be very confusing.

[mark-i-m]

If the panic is in a library you didn't write, the line numbers will be meaningless anyway. Instead, you would look at the error message and try to find the offensive code in your own work, right ?

…

On Jul 12, 2017 8:24 AM, "Jake Goulding" ***@***.***> wrote: How would line numbers in the reported error message work? Right now, panic! uses the line!() and file() macros to grab these. If the panic message says one file (the real location) and the stack trace doesn't include that, it would be very confusing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1744 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIazwJRQEYCmhvI9PaotM7TK2EV-FFm4ks5sNLrfgaJpZM4J4V0x> .

[Centril]

Closing in favor of rust-lang/rust#47809.