0

I tried to use a struct from an external crate which does not use the pub key.

I guess the best fix will be to open a PR but my curiosity get triggered here.

In C++ it is pretty easy. We can do:

#define private public
#include <...> // import public as public AND also private as public
#undef private

This will trick the compiler while parsing the code, so we get access to all the methods/fields of the class.

Any idea for Rust?

Here is a concrete example:

use warp::{
    compression::{Compression, internal::CompressionProps},
    reply::Response,
};

pub enum CompressionAlgorithms {
    Brotli(Compression<dyn Fn(CompressionProps) -> Response>),
    Deflate(Compression<dyn Fn(CompressionProps) -> Response>),
    Gzip(Compression<dyn Fn(CompressionProps) -> Response>),
}

Compile error: error[E0603]: module `internal` is private - in this example, we are trying to import a module and not a structure... Not sure if it changes anything.

Unfortunately, the docs for error E0603 is not really helpful if we do not own the crate. Same for the docs on visibility and privacy in the Rust Reference.

pretzelhammer
  • 13,874
  • 15
  • 47
  • 98
tirz
  • 2,041
  • 1
  • 22
  • 37

1 Answers1

0

Any idea for Rust?

If a crate does not expose something, then that thing is not for you to use. It might be an oversight, or it might be a design decision, that is immaterial.

Compile error: error[E0603]: module internal is private - in this example, we are trying to import a module and not a structure... Not sure if it changes anything.

No. Hell, the naming scheme is literally telling you that the private module is internal details, it couldn't be any clearer that this is very much not intended for you to touch. CompressionProps was specifically made non-public.

Masklinn
  • 34,759
  • 3
  • 38
  • 57
  • Yeah, the example is maybe not perfect. In fact my question is more a challenge to find a way to bypass the Rust compiler class-visibility... Even if it is a dirty and unsafe hack which ignore any design decision. – tirz Nov 02 '20 at 07:57
  • 4
    Well, you always can just clone the crate sources, modify them and use the local copy as dependency, if you're not going to publish your crate yourself. Aside from that - no, there's no way to modify source code of the dependency from the dependent. – Cerberus Nov 02 '20 at 08:05
  • 1
    Which is, in fact, is what `#include` does. It expands to entire contents of the included file. – Ivan C Nov 02 '20 at 11:53
  • 1
    Which is also why C++ compilers have to keep re-parsing the same files over and over and over again and [chromium starts with 12 million LOCs but by the time it's done the compiler has gone through 3.6 billion LOCs](https://randomascii.wordpress.com/2020/03/30/big-project-build-times-chromium/). – Masklinn Nov 02 '20 at 12:21
  • @Cerberus Would you like to make that into an answer? It really is the only way to do what the OP is asking for. – trent Nov 02 '20 at 13:06