Moving the discussion about improving the maintainability of the current prepared ASTs from #2 (comment) to here.

As an example, my solution resulted in the comment "Consider expanding the solution to pass the feature-gated test_grapheme_clusters test case..."

#[cfg(feature = "grapheme")]
use unicode_segmentation::UnicodeSegmentation;

#[cfg(not(feature = "grapheme"))]
pub fn reverse(input: &str) -> String {
    input.chars().rev().collect()
}

#[cfg(feature = "grapheme")]
pub fn reverse(input: &str) -> String {
    input.graphemes(true).rev().collect()
}

I assume the #[cfg()] blocks are tripping it up. I'm afraid I don't have a suggestion for fixing this but I'm sure it's an interesting challenge for someone to tackle at some point :)

The current implementation of the lint functions in the lints.rs module consists of a great number of the deeply nested if let statements with the intermediate logic inside the condition blocks.

Some block could not be avoided, since the dyn keyword inside the pattern matches is not stable yet, but even without it there is a lot of repetitive and hard to maintain code, which potentially can migrate to the other exercise analyzers.

So it would be great to see if the code could be somehow refactored for better readability/maintainability.

The analyzer currently matches full ASTs:

This works, but is inflexible: it is currently impossible to suggest both implementing the bonus test and also removing use statements. We could refactor for greater flexibility by writing this more like a linter.

Detailed proposal:

1. Add a static LINTS: Vec<dyn Fn(&File, &mut AnalysisOutput) -> Result<()>>

2. Populate this list with functions which look for particular features of the input file. For example:

   • one might look for the presence of use statements, and add a suggestion that those aren't necessary in Rust 2018
   • one might look for the absence of use of the unicode_segmentation crate, and suggest that this would be an easy way to implement the bonus feature
   • one might compare the body of the reverse function (ignoring the variable name) with the ideal output, and approve if it is optimal

   These functions have the option to return an error, aborting the parse, but generally they should be OK.

3. Refactor the main Analyze implementation such that by default, it has a basic "refer to mentor" output. Every lint in the LINTS list is run, possibly modifying the output. If any lint returns an Err, the break out of the lints iteration and return an appropriate error.

4. Once every lint has run, simply return the fully-mutated AnalysisOutput.

5. Remove most of the existing PreparedOutput stuff, which should no longer be needed or used.

I believe that this architecture would be sufficient to close #5.

This is on a mentoring request, but I have also seen this when I am doing exercises myself.

The specific mentoring request is for gigasecond, and the code from the mentoring request is:

use time::PrimitiveDateTime as DateTime;
use time::Duration as Duration;

// Returns a DateTime one billion seconds after start.
pub fn after(start: DateTime) -> DateTime {
    start + Duration::seconds(1000000000)
}

Running this crate locally on that code gives:

{
  "status": "refer_to_mentor",
  "comments": [
    "The solution could not be parsed."
  ]
}

But I do not know if that is what the live site is giving.

The current version of the reverse-string analyzer does a very primitive version of the analysis - read the solution AST and compare it with a bunch of prepared ASTs to give a approve_as_optimal or approve_with_comment status.

The prepared ASTs can be viewed in the reverse-string README.

The following work should be done:

• Make the AST analysis more thorough
• Expand the approve solution list
• Make the analyzer return the disapprove status

https://github.com/exercism/rust-analyzer/blame/5b6d04d24d5163bbc5faf647cc20195d0e4da887/README.md#L3

Interface link returns 404.

The rust analyzer detects a syntax error in my solution, although there is none.
https://exercism.org/tracks/rust/exercises/roman-numerals/solutions/geri1701