Skip to content
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

Closed
bitzoic opened this issue Feb 25, 2023 · 6 comments · Fixed by #4548
Closed

Weird formatting with commented out functions and docs #4185

bitzoic opened this issue Feb 25, 2023 · 6 comments · Fixed by #4548
Assignees
Labels
bug Something isn't working formatter

Comments

@bitzoic
Copy link
Member

bitzoic commented Feb 25, 2023

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:

    /// This is documentation for a commented out function
    // fn commented_out_function() {
    //}

    fn test_function() -> bool {
        true
    }

After formatting we have the following:

    /// This is documentation for a commented out function

        // fn commented_out_function() {
    //}
fn test_function() -> bool {
        true
    }

Tested with v0.35.3

@bitzoic bitzoic added bug Something isn't working formatter labels Feb 25, 2023
@eightfilms
Copy link
Contributor

eightfilms commented Apr 6, 2023

Could you provide a minimal repro that is runnable through forc-fmt? i.e. running forc-fmt <file> works.

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

@bitzoic
Copy link
Member Author

bitzoic commented Apr 10, 2023

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
    }
}

@Lukasz2891
Copy link

In v.0.37.1 after having commented out some number of lines it adds lot of empty lines before the commented code :)

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;
// }

@bitzoic
Copy link
Member Author

bitzoic commented Apr 18, 2023

In v.0.37.1 after having commented out some number of lines it adds lot of empty lines before the commented code :)

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

@eightfilms
Copy link
Contributor

Thank you for the examples/repros! Would be super helpful in fixing these bugs @bitzoic @Lukasz2891

@eightfilms
Copy link
Contributor

Created a new issue #4473 for @Lukasz2891 's bug, because they're separate issues.

eightfilms added a commit that referenced this issue May 9, 2023
…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.
crodas added a commit that referenced this issue Dec 5, 2023
This was discovered while adding tests for #2790, #2497. This is a
regression from #4185
crodas added a commit that referenced this issue Dec 5, 2023
This was discovered while adding tests for #2790, #2497. This is a
regression from #4185
crodas added a commit that referenced this issue Dec 5, 2023
This was discovered while adding tests for #2790, #2497. This is a
regression from #4185
crodas added a commit that referenced this issue Dec 5, 2023
This was discovered while adding tests for #2790, #2497. This is a
regression from #4185
crodas added a commit that referenced this issue Dec 5, 2023
## 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working formatter
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants