The reverse string exercise from the rust track includes a bonus task related to optional dependencies and cargo feature flags.
I have satisfied the test in my local setup, but I fail to find a way to convince exercism to enable the “grapheme” flag during test execution.
What am I missing? :)
Cargo.toml
[dependencies]
unicode-segmentation = {version = "1.10", optional=true}
[features]
grapheme = ["unicode-segmentation"]
[package]
edition = "2021"
name = "reverse_string"
version = "1.2.0"
lib.rs
#[cfg(feature = "grapheme")]
use unicode_segmentation::UnicodeSegmentation;
pub fn reverse(input: &str) -> String {
#[cfg(feature = "grapheme")]
return input.graphemes(true).rev().collect();
input.chars().rev().collect()
}
Submitted with: exercism submit src/lib.rs Cargo.toml
The exercism test runner can’t download dependencies not included in the language.
Oh okay - so is it impossible to get exercism that the bonus task was solved then?
Because here’s the hint I get after solving the task:
Our Rust Analyzer has some comments on your solution which may be useful for you:
Consider expanding the solution to pass the feature-gated test_grapheme_clusters test case. Understanding how Unicode graphemes can be handled and how to use external crates, has great benefits down the line.
That is odd, but reading the cargo files in the test runner and it doesn’t mention this package (since you can preload packages), and this feedback maybe was only meant for the local machine?
While true in general, I’m not sure this is the issue here.
I have previously submitted Rust solutions that used external packages, and the result was a timeout (probably due to slow compilation), rather than an error explicitly caused by e.g. lack of internet access.
@theCalcaholic what was the exact error message?
I am unsure but in general, the test runner docker containers are setup with --network none. And the run-in-docker.sh file for the rust test runner also has that tag. But perhaps the docker container that rust runs the rust test runner in has a special setup?
I don’t get an error. The bonus task (and the related tests and code) are just ignored, because the --feature grapheme argument doesn’t seem to be present when exercism runs the tests.
I only receive the hint mentioned here
While it’s true that the test runners don’t have internet access and in general cannot install 3rd-party dependencies, the Rust test runner has built-in support for some popular crates. The list is here:
In the case of this exercise, using the optional grapheme feature should work. I don’t think you need to submit the Cargo.toml file though - maybe that’s why it doesn’t work in your case?
I actually tried submitting only lib.rs first - that didn’t work either. 
I looked back at my own submission and realized I had the same issue: the optional grapheme test was not run. I managed to convince the test runner to execute it by adding the grapheme feature to the list of default features and submit the Cargo.toml file along with src/lib.rs.
My published solution is here:
Reverse String in Rust on Exercism
If you look at the changes I made to Cargo.toml and do the same on your end it should work. (This might be considered a “bug”, or at the very least an annoyance, in the exercise, I guess…)
I’ve looked into this, and I can get it to work with the following Cargo.toml:
[dependencies]
unicode-segmentation = "1.9.0"
[features]
default = ["grapheme"]
grapheme = []
[package]
edition = "2018"
name = "reverse_string"
version = "1.2.0"
Thanks, that did the trick!
Not sure if it’s a bug or a documentation issue, but fixing it in either location would be nice 
Interestingly, while the optional test was run after adding “grapheme” to the default feature set, I still received the following comment from the analyzer:
Consider expanding the solution to pass the feature-gated test_grapheme_clusters test case. Understanding how Unicode graphemes can be handled and how to use external crates, has great benefits down the line.
Odd. Maybe someone from the Rust team could look into this?
Would you be interested in submitting a PR?
Had a quick glance at the analyzer responsible for the suggestion, it seems like that’s generated based on AST analysis, not whether or not the bonus tests pass. To fix it one would have to make the AST analysis more sophisticated. Not sure it’s worth the effort.
Adding the default feature to the exercise documentation seems like a good idea, ideally we’d do that for all exercises with feature-gated bonus tests at the same time. I’d be glad to review a PR.
Turns out this exact issue was already filed on the repo a while ago.
