test: fix "cargo test" after cst change.

[wxsBSD]

I apparently don't understand enough about rust to know why it is running test code from comments, but it apparently is.

[ghost]

Hi team,

I'm currently reviewing this pull request and will provide my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly understand the changes:

This pull request aims to fix the "cargo test" failures that arose after a change in the Concrete Syntax Tree (CST). The author, wxsBSD, mentions a lack of understanding of why test code was being run from comments, leading to this fix.

The changes involve modifying the parser/src/cst/mod.rs file. Specifically, the into_cst() method calls within the doc comments have been replaced with try_into_cst().unwrap(). This change appears in multiple locations within the doc comments of the Token and Node implementations:

• Line 429, 468, 759, 803: into_cst() changed to try_into_cst().unwrap() in doc comments for Token methods.
• Line 759, 803: into_cst() changed to try_into_cst().unwrap() in doc comments for Node methods.

This suggests a potential issue with error handling or the previous implementation's interaction with test code within comments. The try_into_cst() method likely provides more robust error handling, preventing the unexpected execution of test code.

I'll provide a more detailed review soon, but this summary should give you a head start.

And now, a little haiku to lighten the mood:

Tests fail, code's changed,
Comments run, a mystery solved,
Rust's secrets revealed.

[ghost]

This change updates the example code in documentation comments to reflect the change from .into_cst() to .try_into_cst().unwrap(). It's good practice to keep documentation and code synchronized. There are no changes to the functionality of the code itself.

[ghost]

Since try_into_cst can return an error, it's good that you've added .unwrap() to handle the Result. However, the documentation example should ideally demonstrate proper error handling instead of simply unwrapping. Would you consider adding a check for the Result and handling the error gracefully in the example?

///     .try_into_cst()
///     .expect("failed to convert to CST")

[ghost]

Since try_into_cst can return an error, it's good that you've added .unwrap() to handle the Result. However, the documentation example should ideally demonstrate proper error handling instead of simply unwrapping. Would you consider adding a check for the Result and handling the error gracefully in the example?

///     .try_into_cst()
///     .expect("failed to convert to CST")

[ghost]

Since try_into_cst can return an error, it's good that you've added .unwrap() to handle the Result. However, the documentation example should ideally demonstrate proper error handling instead of simply unwrapping. Would you consider adding a check for the Result and handling the error gracefully in the example?

///     .try_into_cst()
///     .expect("failed to convert to CST")

[ghost]

Since try_into_cst can return an error, it's good that you've added .unwrap() to handle the Result. However, the documentation example should ideally demonstrate proper error handling instead of simply unwrapping. Would you consider adding a check for the Result and handling the error gracefully in the example?

///     .try_into_cst()
///     .expect("failed to convert to CST")

[plusvic]

I apparently don't understand enough about rust to know why it is running test code from comments, but it apparently is.

Rust encourages you to write code examples that are also tests, precisely to prevent cases like this one, where the documentation gets out-of-date due to changes in the actual code.