Support dev comments

[drahnr]

Is your feature request related to a particular use-case?

Dev comments could contain spelling mistakes too.

Describe the solution you'd like to implement/see implemented

A file containing // or /*! .. */ based comments should also be spell checked.

Describe alternatives you've considered

Status quo. Do not check them.

[snasphysicist]

Hi @drahnr I would like to have a go at implementing this improvement please, if that's okay?

[drahnr]

@snasphysicist that'd be awesome! The relevant code would mostly around https://github.com/drahnr/cargo-spellcheck/blob/master/src/documentation/literal.rs#L60-L164 - currently syn is used, but this implies that // and /*! */ type comments are not part of the syntax tree, but must be extracted differently.

I assume either applying another rust syntax parser (not sure how many usable there are, rust-analyzer comes to mind) would be an option, manual parsing is probably quite dire.

Feel free to open a PR, I am happy to review this early and often :)

[drahnr]

@snasphysicist anything I can help with to get you started?

[snasphysicist]

Hi @drahnr some slow progress is being made - I've been playing with rust_analyzer and rustc to extract the comments' contents from the source files though I haven't yet looked at how to fit this into cargo-spellcheck. I'll link to Rust playground to show how this looks when I've tidied my experiments a bit.

[drahnr]

What you described sounds like a good path forward ( the extracted syntax parser lib of ra is https://lib.rs/crates/ra_ap_syntax )

[snasphysicist]

Hmm maybe I am using a slightly out of date version of rust_analyzer. The crate I found was ra_syntax, probably not too different to the one you mention. Anyway I realised that a playground link is not so useful because I guess dependencies aren't supported, so I put a slightly tidied experiment in this gist.

Neither rustc nor rust_analyzer is especially difficult to work with. Unless there are some complexities I've missed I think rust_analyzer is a better candidate because it requires a little less manual work to produce something useful.

If you're happy with the basic idea here, I'll start looking at how to integrate this into the existing cargo-spellcheck source. Let me know if you have any comments/suggestions, thanks!

[drahnr]

The gist looks good! I would recommend to take a look at CheckableChunk which is clustered set of Literals to not re-impl it as part of the parser, most of the algorithms built on top of CheckableChunk, so changes there have possible larger fallout effects.

Most of your changes should be in https://github.com/drahnr/cargo-spellcheck/blob/master/src/documentation/literal.rs#L60-L164 (or its vicinity).

Looking forward to your PR!

[snasphysicist]

Hi @drahnr i've opened a WIP PR #130 since I think the feature is getting close to being implemented. Happy to hear any feedback or thoughts. Note that the individual commits might be a bit untidy, I'll tidy them up later where required.