-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weird formatting with commented out functions and docs #4185
Comments
Could you provide a minimal repro that is runnable through I tried it with something like: contract;
/// This is documentation for a commented out function
// fn commented_out_fn() {
// }
fn test_function() -> bool {
true
} which turns into: contract;
/// This is documentation for a commented out function
fn test_function() -> bool {
true
} Not exacly the same output that was posted here though it is still an issue |
Using forc v0.37.0 I used this input: contract;
abi MyContract {
fn test_function() -> bool;
}
impl MyContract for Contract {
/// This is documentation for a commented out function
// fn commented_out_function() {
//}
fn test_function() -> bool {
true
}
} This is the following formatting output: contract;
abi MyContract {
fn test_function() -> bool;
}
impl MyContract for Contract {
/// This is documentation for a commented out function
// fn commented_out_function() {
//}
fn test_function() -> bool {
true
}
} |
In library;
use std::{u256::U256, vec::*};
use ::utils::vec::sort;
use ::utils::numbers::*;
// pub fn aggregate_results(results: Vec<Vec<U256>>) -> Vec<U256> {
// let mut aggregated = Vec::new();
// let mut i = 0;
// while (i < results.len) {
// let values = results.get(i).unwrap();
// aggregated.push(aggregate_values(values));
// i += 1;
// }
// return aggregated;
// } is formatted to library;
use std::{u256::U256, vec::*};
use ::utils::vec::sort;
use ::utils::numbers::*;
// pub fn aggregate_results(results: Vec<Vec<U256>>) -> Vec<U256> {
// let mut aggregated = Vec::new();
// let mut i = 0;
// while (i < results.len) {
// let values = results.get(i).unwrap();
// aggregated.push(aggregate_values(values));
// i += 1;
// }
// return aggregated;
// } |
I have seen this in a number of files in the sway-libs repository as well |
Thank you for the examples/repros! Would be super helpful in fixing these bugs @bitzoic @Lukasz2891 |
Created a new issue #4473 for @Lukasz2891 's bug, because they're separate issues. |
…f spans (#4548) Closes #4185 ## Description The solution we adopted as a start would have us take the space between leaf spans, except a problem was that a doc comment would be a leaf span but a regular comment would not be a leaf span. Usually this would not be an issue, but in certain cases where we perhaps want to comment code out temporarily to test changes, the formatter would move comments around unintentionally. For example, a doc comment followed by a commented out function (as shown in the issue) would cause the commented out function to move away from the doc comment: ```rust contract; abi MyContract { fn test_function() -> bool; } impl MyContract for Contract { /// This is documentation for a commented out function <-- a newline is inserted after this comment // fn commented_out_function() { //} fn test_function() -> bool { true } } ``` Situations like these could ruin developer experience. The main problem is that the entire whitespace gap between 2 leaf spans could have multiple comments with multiple newline sequences, and all these would be squished to the end of the first leaf span when inserting the newlines. The fix is to take 'snippets' while we're scanning for newline sequences to insert and try to detect comments within these snippets. We then split insertion of newline sequences into two phases: one before the first comment (which is described above, which caused the issue above), one after the last comment. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.
## Description This was discovered while adding tests for #2790, #2497. This is a regression from #4185 ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [x] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [x] I have added tests that prove my fix is effective or that my feature works. - [x] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.
When commenting out a function and there is a doc above the function, we see the following weird formatting behavior.
This is our code before formatting:
After formatting we have the following:
Tested with v0.35.3
The text was updated successfully, but these errors were encountered: