Investigate the issue of `Show` bloat

[emberian]

In rustc, many types derive Show purely for use with debug!. This may be negatively impacting compiletime, as we are generating and translating code that we really don't care about most of the time. Is this causing noticable impact, and do we want to do anything about it?

[emberian]

One possibility is add a #[deriving(DebugShow)] that is not emitted when --cfg ndebug (or today's equivalent) is used. It would then be the programmer's responsibility to ensure they are not using it outside of debug! logging.

[emberian]

cc @huonw

[huonw]

We could do this via (hypothetical) conditional attributes

#[cfg_attr(not(ndebug), deriving(Show))]
struct Foo { ... }

or even a more specific version: #[debug_only(deriving(Show))].

cfg_attr/debug_only can be done with a ItemModifier syntax extension, but it may be ugly to hard code it into libsyntax (it could be e.g. #[__cfg_attr(...)] for now, or just go via an RFC) and doing it as a rustc-specific thing may hit staging issues.

(Theoretically we should be bootstrapping/testing with ndebug anyway.)

[huonw]

I guess we could even have

#[cfg(not(ndebug))]
macro_rules! debug_show {
    ($($it: item)*) => {
        $(
          #[deriving(Show)] $it
        )*
    }
}
#[cfg(not(ndebug))]
macro_rules! debug_show {
    ($($it: item)*) => {
        $( $it )*
    }
}

debug_show! {
    struct Foo { ... }
    enum Bar { ... }
}

This would be easy to be specific to libsyntax/librustc and doesn't require an external plugin, but is also kinda ugly.

[lilyball]

Any sort of debug-only Show impl means clients of your crate can't debug using your types. For example, clients of libsyntax won't be able to debug libsyntax-provided values if libsyntax adopted this sort of DebugShow.

Any sort of compile-time solution to this problem is very problematic. It involves allowing each client crate to re-derive its own Show instance and I can't see that working well.

Perhaps the best approach is to expand TyDesc to also provide info about specially-marked traits (which in this case would just be Show). If the debug reflection can construct a &Show at runtime for a type that implements it, then it could use this to print a derived-Show-like representation of a type at runtime without having to derive it at compile-time. A big advantage of this approach is it should work for any type without having to modify the type definition, which is a big help when debugging values from other crates (e.g. clients of libsyntax printing AST values).

We could also add a DebugShow trait that would be used instead of Show if implemented, thus allowing types to provide more information about themselves for debugging purposes.

[lilyball]

Note: I have not actually looked at TyDesc or the runtime reflection in libdebug, so I'm making some assumptions here about the plausibility of adding the Show info.

[emberian]

Sure they can, just don't pass --cfg ndebug when the crate is built. This
is not much different than building an asserts or debuginfo build.

On Fri, Jul 11, 2014 at 7:07 PM, Kevin Ballard notifications@github.com
wrote:

Note: I have not actually looked at TyDesc or the runtime reflection in
libdebug, so I'm making some assumptions here about the plausibility of
adding the Show info.

—
Reply to this email directly or view it on GitHub
#15548 (comment).

http://octayn.net/

[lilyball]

@cmr If I have a no-debug version of Rust on my system (FWIW offhand I don't remember anymore if the default Rust configuration uses --cfg ndebug), and I want to write a program that uses libsyntax, and I need to debug some of the values libsyntax gave me, recompiling and reinstalling all of Rust is a bit of a serious hurdle.

[emberian]

I don't really see that as a problem. That's how all C and C++ software
works in practice. I suppose whether regressing to C/C++'s level is worth
it or not depends on how much bloat this actually causes. Someone should
investigate ;)

On Fri, Jul 11, 2014 at 7:24 PM, Kevin Ballard notifications@github.com
wrote:

@cmr https://github.com/cmr If I have a no-debug version of Rust on my
system (FWIW offhand I don't remember anymore if the default Rust
configuration uses --cfg ndebug), and I want to write a program that uses
libsyntax, and I need to debug some of the values libsyntax gave me,
recompiling and reinstalling all of Rust is a bit of a serious hurdle.

—
Reply to this email directly or view it on GitHub
#15548 (comment).

http://octayn.net/

[lilyball]

@cmr You don't typically have to recompile the language to turn on debugging functionality :P

[huonw]

You're not recompiling the language; you're just getting debug builds of the libraries you're using (which happen to be the compiler/parser). It's perfectly possible to build only those 2 crates in debugging mode directly, without a full bootstrap.