Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom file output format #27

Closed
hexfusion opened this issue Aug 20, 2022 · 4 comments
Closed

Custom file output format #27

hexfusion opened this issue Aug 20, 2022 · 4 comments

Comments

@hexfusion
Copy link

As per the docs:

A package named helloworld.abstract.v1 will have an output filename of helloworld.abstract.v1.rs.

While this is a nice readable format having a dot in the file name makes it incompatible with rust for use directly with mod. The result is we are required to use include macro. But IDE's such as vscode with rust extension are unable to reference the definition for traits etc. This is sort of a big deal for developer UX.

If we allowed the separator to be configurable IE _ helloworld_abstract_v1.rs. would be valid. That would allow the below which also allows visibility into the trait source via IDE.

mod helloworld_abstract_v1;
mod helloworld_abstract_v1_tonic;

#[cfg(feature = "helloworld")]
pub mod helloworld {
    pub use super::helloworld_abstract_vs::*
    pub use super::helloworld_abstract_vs_tonic::*
}

I imagine this would mess with your prost-crate assumptions so perhaps we could gate this an not compatible? Or better yet we could adopt this output? :)

@hexfusion hexfusion changed the title Custom output format Custom file output format Aug 21, 2022
@neoeinstein
Copy link
Owner

Much of this goes back to how prost-build is set up to generate these files. It makes certain assumptions about the module structure between various elements, and protoc-gen-prost-crate uses those conventions in setting up the includes.

In my case, I regularly use Visual Studio Code with the rust-analyzer plugin, and I don't seem to have the same issue that you appear to be indicating you have. I tried this in two fashions, from within and without the same crate where the definitions are being included, and I had no problems getting VSCode to bring up the trait methods:

image

Of note, the rust-analyzer plugin filters out functions for traits that aren't in scope. Thus, when I just press . without having prost::Message imported, I only see the following:

image

But, if I have already imported prost::Message into the file with use prost::Message, then I see this:

image

If you're more worried about the fact that "Go to definition" leads you to the include!() macro invocation, that is a limitation of rust-analyzer (rust-lang/rust-analyzer#3767 and rust-lang/rust-analyzer#9403). I'm not keen to add and support a new feature just to work around a tooling issue that should be fixed on that side.

@neoeinstein
Copy link
Owner

While this is a nice readable format having a dot in the file name makes it incompatible with rust for use directly with mod.

Note that if you want this, you can specify the path manually with an attribute:

#[path = "helloworld.abstract.v1.rs"]
mod helloworld_abstract_v1;

@hexfusion
Copy link
Author

Everything for the most part works fine with vscode but if I do [go to definition] I always land on the root include. Which I guess we can't completely blame on the implementation. I appreciate the feedback.

image

@hexfusion
Copy link
Author

While this is a nice readable format having a dot in the file name makes it incompatible with rust for use directly with mod.

Note that if you want this, you can specify the path manually with an attribute:

#[path = "helloworld.abstract.v1.rs"]
mod helloworld_abstract_v1;

Nice this actually helps me a lot, had not tried that. Will close this as we have a viable workaround. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants