Add the ability to open a specific module when running cargo doc --open

[shepmaster]

I'm in the process of documenting a library, so I'm doing a lot of:

1. Edit source
2. Build docs
3. Look at docs

This is great because my editor has a command for running cargo doc --open, so the cycle is pretty tight. However, when I start documenting a module, I have to click a few times before I can start reading. It'd be neat to be able to do something akin to cargo doc --open --module my::cool::module.

For opening to a specific package, see #10516

[DarkDrek]

I want to do this.

Wouldn't it be better to use cargo doc --open [module] as command instead of cargo doc --open --module <module>.
With [module] as optional argument to --open so just that without it we fallback to the current behavior?

For parsing the module would it be preferred to use something like https://github.com/dtolnay/syn ?

[shepmaster]

Wouldn't it be better to use

I don't really have a strong preference for the specific command line argument, personally.

would it be preferred to use something like

I don't think I'm following why you need to parse the source code here; shouldn't you just be able to map the argument foo::bar to foo/bar.html (or appropriate path)?

[DarkDrek]

I don't think I'm following why you need to parse the source code here; shouldn't you just be able to map the argument foo::bar to foo/bar.html (or appropriate path)?

That was also my first thought but what if the user enters foo::../ or something like that which isn't a valid module path but a valid filesystem path?
Maybe it would be enough to simply check whether the build path is still within the doc directory. The possible endpoints are currently index.html if the last item is a module and .t.html for everything (enum, struct) else.

[shepmaster]

but what if the user enters foo::../ or something like that which isn't a valid module path but a valid filesystem path?

I don't see why that should be supported. If the user wants to pass a filesystem path, they can just chain the build command with their OS command. For example, I could do cargo doc && open target/.../mod/foo.rs

I don't understand why someone would combine modules and filesystem paths either.

[DarkDrek]

That's why I'm currently trying to find a method to prevent or mitigate that:

• Using a real module path parser
  • Would a new dependency
• Using a black/white-list of allowed characters
  • Can be too harsh rejecting valid module paths or allow invalid input
• Checking whether the resulting path is within the doc directory
  • Would not prevent the invalid input but the generated paths shouldn't cause any harm

Another thing that is currently unanswered for me is if rustdoc applies some transformation to the module path segments to map them to directory and file names? If yes are they documented somewhere?

Edit:
I have implemented option 3 here