refactor - improved error regarding issue "Better error message #6302" #6310

rufevean · 2024-09-01T15:09:38Z

ytmimi · 2024-09-01T20:29:07Z

src/config/mod.rs

+    pub(super) fn from_toml(toml: &str, dir: &Path,file_path : &Path) -> Result<Config, String> {
+        Self::from_toml_for_style_edition(toml, dir,file_path, None, None, None)


We don't need to pass both dir and file_path. The dir can easily be derived from the file path.

ytmimi · 2024-09-01T20:34:44Z

src/config/mod.rs

        dir: &Path,
+        file_path: &Path,


Same goes for this. We don't need to pass both the dir and file_path. We can derive the dir from the file_path.

rufevean · 2024-09-01T20:58:35Z

i cant figure out why my tests are failing, could you please guide me through this?

ding-young · 2024-09-02T16:53:10Z

i cant figure out why my tests are failing, could you please guide me through this?

It looks like the self-tests didn't pass. Since it's important for the rustfmt source code to adhere to the same formatting style that it enforces, the self-test runs rustfmt on its own codebase. You can find more details in the Contributing.md.

To resolve this, you might want to try running cargo run --bin rustfmt /path/to/modified/source.rs to format the modified source code using the rustfmt built from the source. After that, you can check if the tests pass locally by running cargo test.

Hope this helps!

rufevean · 2024-09-03T06:50:49Z

@ytmimi i think its ready for review now, thank you

ytmimi

Thanks for continuing to look into this. I've left a few comments inline. Also, I think it would be great if we could add a unit test similar to those defined here, where we call the rustfmt binary and check the content of stdout / stderr.

In this case we can create a new config file in tests/config that will trigger the error, and we can call rustfmt with the --config-path argument and validate that we see our expected error message in stderr.

Also, one more note. The rustfmt team strongly discourages merge commits. Please rebase your branch to bring it up to date when you get a chance.

ytmimi · 2024-09-03T15:44:54Z

src/config/mod.rs

-                Ok(parsed_config.to_parsed_config(style_edition, edition, version, dir))
+                Ok(parsed_config.to_parsed_config(style_edition, edition, version, file_path))


Can you double check what PartialConfig::to_parsed_config does with the dir argument. Although the types match up before the method expected a directory path and now we're passing a file path so that could change behavior. We probably need to derive the dir from the file path here.

Correct me if i am wrong, to_parsed_config() only uses dir arguement for fill_from_parsed_config(self,dir)

pub(super) fn to_parsed_config( self, style_edition_override: Option<StyleEdition>, edition_override: Option<Edition>, version_override: Option<Version>, dir: &Path, ) -> Config { Config::default_for_possible_style_edition( style_edition_override.or(self.style_edition), edition_override.or(self.edition), version_override.or(self.version), ) .fill_from_parsed_config(self, dir) } }

and

fn fill_from_parsed_config(mut self, parsed: PartialConfig, dir: &Path) -> Config { $( if let Some(option_value) = parsed.$i { let option_stable = self.$i.3; if $crate::config::config_type::is_stable_option_and_value( stringify!($i), option_stable, &option_value ) { self.$i.1 = true; self.$i.2 = option_value; } } )+ self.set_heuristics(); self.set_ignore(dir); self.set_merge_imports(); self.set_fn_args_layout(); self.set_hide_parse_errors(); self.set_version(); self }

The dir parameter is used only in the self.set_ignore(dir) method call, i think its to specifiy which files or directories to ignore based on the provided directory path.

Thanks for looking into this. Given that code down the stack needs the dir we need to pass that along.

Ok(parsed_config.to_parsed_config(style_edition, edition, version, file_path.parent().unwrap_or(Path::new(""))))

can we refactor that statement to this so that we can also pass dir ?

I think it's fine to just call file_path.parent().unwrap() since that's what from_toml_path did before your change.

but if its unwrap() . wont we pass a None value if its empty? and isnt that an error?

i have followed your approach and tried just using unwrap() and then tested it, i got this output

---- config::test::test_unstable_from_toml stdout ---- thread 'config::test::test_unstable_from_toml' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::deprecated_option_merge_imports::test_new_overridden stdout ---- thread 'config::test::deprecated_option_merge_imports::test_new_overridden' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::deprecated_option_merge_imports::test_both_set stdout ---- thread 'config::test::deprecated_option_merge_imports::test_both_set' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ---- config::test::deprecated_option_merge_imports::test_old_overridden stdout ---- thread 'config::test::deprecated_option_merge_imports::test_old_overridden' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::deprecated_option_merge_imports::test_old_option_set stdout ---- thread 'config::test::deprecated_option_merge_imports::test_old_option_set' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::test_was_set stdout ---- thread 'config::test::test_was_set' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::use_small_heuristics::test_array_width_config_exceeds_max_width stdout ---- thread 'config::test::use_small_heuristics::test_array_width_config_exceeds_max_width' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::use_small_heuristics::test_attr_fn_like_width_config_exceeds_max_width stdout ---- thread 'config::test::use_small_heuristics::test_attr_fn_like_width_config_exceeds_max_width' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value ---- config::test::use_small_heuristics::test_chain_width_config_exceeds_max_width stdout ---- thread 'config::test::use_small_heuristics::test_chain_width_config_exceeds_max_width' panicked at src/config/mod.rs:401:40: called `Option::unwrap()` on a `None` value

Am i missing something?

@ytmimi , what approach should i prefer here?

ytmimi · 2024-09-03T15:58:44Z

src/config/mod.rs

+                let config_file_path_str = file_path.to_string_lossy();
+
+                let err_msg = format!(
+                    "The file `{}` failed to parse.\n\
+                         Error details: {}\n\
+                         Help: Ensure that the configuration file at `{}` is correctly formatted.",
+                    config_file_path_str, e, config_file_path_str
+                );
+
+                Err(err_msg)


We should still add the err_msg to the err String and return that since it might contain additional error details. Also, I think we can simplify the error message as follows since you've already told the user the path to the file on the first line:

let err_msg = format!( "The file `{}` failed to parse.\n Error details: {e}", file_path.display() ); err.push_str(&err_msg) Err(err)

yes i agree that your approach is much better and is also working, i have changed the code accordingly

rufevean · 2024-09-04T12:07:41Z

Thanks for continuing to look into this. I've left a few comments inline. Also, I think it would be great if we could add a unit test similar to those defined here, where we call the rustfmt binary and check the content of stdout / stderr.

In this case we can create a new config file in tests/config that will trigger the error, and we can call rustfmt with the --config-path argument and validate that we see our expected error message in stderr.

okay, so we have to write a test case in tests/rustfmt/main.rs that takes the file we create in tests/config which is faulty and we should expect the output as an error, right?

Also, one more note. The rustfmt team strongly discourages merge commits. Please rebase your branch to bring it up to date when you get a chance.

would it be better if i do once we have finalized all the refactoring?

ytmimi · 2024-09-04T17:29:42Z

okay, so we have to write a test case in tests/rustfmt/main.rs that takes the file we create in tests/config which is faulty and we should expect the output as an error, right?

Yeah, thats right.

would it be better if i do once we have finalized all the refactoring?

Sure. Just wanted to make you aware of our stance on merge commits.

rufevean · 2024-09-05T11:39:13Z

@ytmimi , why trying to test this issue, i faced two issues

when we raise the error , we get

The file `/home/rufevean/shitbox/rustfmt/tests/config/issue-6302.toml` failed to parse.
Error details: invalid type: integer `2019`, expected string
in `edition`

we get the entire path . so we cant test it that way as the absolute path will change for every person. so i think we might have to refactor the code where it will only present the path from the main project directory?

in the error display

The file `/home/rufevean/shitbox/rustfmt/tests/config/issue-6302.toml` failed to parse.
Error details: invalid type: integer `2019`, expected string
 in `edition`

the in edition part is forming a new line , to track that issue we might have to tract the {e} directly as of my knowledge, we didnt specify anything that makes it in a new line.

ytmimi · 2024-09-05T15:21:45Z

we get the entire path . so we cant test it that way as the absolute path will change for every person. so i think we might have to refactor the code where it will only present the path from the main project directory?

How exactly are you trying to test this? I think it should be doable. If you could add a commit with your test code that would be helpful for me to review and provide some suggestions.

the in edition part is forming a new line , to track that issue we might have to tract the {e} directly as of my knowledge, we didnt specify anything that makes it in a new line.

If you look at the original issue the in edition was also on a newline. It's maybe not that visually appealing, but I don't think it's something we need to address right now.

rufevean · 2024-09-06T19:39:26Z

@ytmimi , i have added the commit, could you please check it and let me know where i am getting it wrong?

ytmimi · 2024-09-07T00:41:19Z

tests/rustfmt/main.rs

+#[test]
+fn rustfmt_error_improvement_regarding_invalid_toml() {
+    // See also https://github.com/rust-lang/rustfmt/issues/6302
+    let args = ["--config-path", "tests/config/issue-6302.toml"];
+    let (_stdout, stderr) = rustfmt(&args);
+
+    let expected_error_message = "The file `rustfmt/tests/config/issue-6302.toml` failed to parse.\n                    Error details: invalid type: integer `2019`, expected string in `edition`";
+
+    assert!(
+        stderr.contains(expected_error_message),
+        "Unexpected error message.\nExpected:\n{}\nGot:\n{}",
+        expected_error_message,
+        stderr
+    );
+}


Nit: add a space between the test and the one above it.

Here's how you can write the test to pass:

#[test] fn rustfmt_error_improvement_regarding_invalid_toml() { // See also https://github.com/rust-lang/rustfmt/issues/6302 let invalid_toml_config = "tests/config/issue-6302.toml"; let args = ["--config-path", invalid_toml_config]; let (_stdout, stderr) = rustfmt(&args); let toml_path = Path::new(invalid_toml_config).canonicalize().unwrap(); let expected_error_message = format!("The file `{}` failed to parse", toml_path.display()); assert!(stderr.contains(&expected_error_message)); }

i have updated it , thank you

ytmimi

Let me know if you'd like to squash the commits / rebase the PR or if you'd rather I just squash the commits on the merge.

rufevean · 2024-09-09T04:42:56Z

Let me know if you'd like to squash the commits / rebase the PR or if you'd rather I just squash the commits on the merge.

i had left a comment regarding Ok(parsed_config.to_parsed_config(style_edition, edition, version, file_path.parent().unwrap_or(Path::new("")))) and i would like to know how do you want me to proceed, and once i have refactored it according to how you think is better. i will rebase it . thank you

ytmimi · 2024-09-09T15:10:48Z

src/config/mod.rs

+                Ok(parsed_config.to_parsed_config(
+                    style_edition,
+                    edition,
+                    version,
+                    file_path.parent().unwrap_or(Path::new("")),
+                ))


As mentioned in #6310 (comment) the previous logic was to unwrap, which is going to panic if we can't get a directory from the file, and i think that's fine (and probably very unlikely to panic in practice).

However we can also just return early with an error:

let dir = file_path.patent() .ok_or_else(|| format!("failed to get parent directory for {}", file_path.display))?; Ok(parsed_config.to_parsed_config( style_edition, edition, version, dir, ))

i have pushed the code now, if the tests past , i will then rebase the code and i think we are good to merge after that?

the tests failed

Yes, you likely need to update all the tests that just pass Path::new(""). to Config::from_toml since we've updated the semantics to pass a file path instead.

let config = Config::from_toml(toml, Path::new("")).unwrap();

so i need to update tests in config dir ?

@rufevean I'd recommend you look into the details of the CI failures, and fix the impacted tests. If it turns out to be more involved than what I just mentioned let me know.

got it, thank you

@ytmimi , i dont know if this is the right approach but i changed
let config = Config::from_toml(toml, Path::new("")).unwrap();
to
let config = Config::from_toml(toml, Path::new(".")).unwrap();
to have current dir as parent dir? and tests got passed

ytmimi · 2024-09-10T15:56:59Z

src/config/mod.rs

-        let config = Config::from_toml("hard_tabs = true", Path::new("")).unwrap();
+        let config = Config::from_toml("hard_tabs = true", Path::new(".")).unwrap();


Let's change this to a file path to better convey that from_toml now expects a file path instead of a directory.

let config = Config::from_toml("hard_tabs = true", Path::new("./rustfmt.toml")).unwrap();

should i do this for every test that takes from_toml or just this?

All of them please

updated , thank you

Turns out there were still a few things that we're working on. Dismissing the old review for now

rufevean · 2024-09-10T18:32:36Z

@ytmimi can we rebase and merge this now?

ytmimi

@rufevean yes, this should be ready now. I'll give you an opportunity to rebase this PR and squash the commits if you'd like to clean up the final commit or I can take care of it. Let me know what you'd prefer.

rufevean · 2024-09-12T05:28:36Z

@ytmimi i think i did something wrong, i rebased it and squashed all my commits into 1. but i can see other's commits here .

ytmimi · 2024-09-12T05:34:23Z

Yeah, definitely doesn't look right. You should be able to get back to the commit before the rebase if you check the git reflog

rufevean · 2024-09-12T06:00:37Z

@ytmimi , i tried squashing it again and deleting the commits that i dont want to include but even then there are some conflicts . its better if you may handle it. thank you

ytmimi · 2024-09-12T06:08:57Z

hmm weird, when I tried to update your branch GitHub marked me as closing the PR 🤔

rustbot added the pr-not-reviewed label Sep 1, 2024

rufevean marked this pull request as draft September 1, 2024 16:29

rufevean mentioned this pull request Sep 1, 2024

Better error message #6302

Closed

ytmimi reviewed Sep 1, 2024

View reviewed changes

rufevean force-pushed the master branch from 489e8fa to d3f72b5 Compare September 1, 2024 20:47

rufevean marked this pull request as ready for review September 3, 2024 06:49

ytmimi reviewed Sep 3, 2024

View reviewed changes

ytmimi added pr-waiting-on-author and removed pr-not-reviewed labels Sep 3, 2024

ytmimi reviewed Sep 7, 2024

View reviewed changes

ytmimi previously approved these changes Sep 9, 2024

View reviewed changes

ytmimi added pr-ready-to-merge and removed pr-waiting-on-author labels Sep 9, 2024

ytmimi reviewed Sep 9, 2024

View reviewed changes

ytmimi reviewed Sep 10, 2024

View reviewed changes

ytmimi added pr-waiting-on-author and removed pr-ready-to-merge labels Sep 10, 2024

ytmimi approved these changes Sep 12, 2024

View reviewed changes

ytmimi added the release-notes Needs an associated changelog entry label Sep 12, 2024

rufevean force-pushed the master branch from 23d9d57 to e05badf Compare September 12, 2024 05:25

rufevean force-pushed the master branch 3 times, most recently from 7930f4f to 23d9d57 Compare September 12, 2024 05:43

ytmimi closed this Sep 12, 2024

ytmimi force-pushed the master branch from 23d9d57 to a1017ae Compare September 12, 2024 06:06

ytmimi mentioned this pull request Sep 12, 2024

refactor - show file path in error message when parsing config from toml #6323

Merged

ytmimi removed pr-waiting-on-author release-notes Needs an associated changelog entry labels Sep 12, 2024

This pull request was closed.

		pub(super) fn from_toml(toml: &str, dir: &Path,file_path : &Path) -> Result<Config, String> {
		Self::from_toml_for_style_edition(toml, dir,file_path, None, None, None)

		Ok(parsed_config.to_parsed_config(style_edition, edition, version, dir))
		Ok(parsed_config.to_parsed_config(style_edition, edition, version, file_path))

		let config = Config::from_toml("hard_tabs = true", Path::new("")).unwrap();
		let config = Config::from_toml("hard_tabs = true", Path::new(".")).unwrap();

refactor - improved error regarding issue "Better error message #6302" #6310

refactor - improved error regarding issue "Better error message #6302" #6310

Conversation

rufevean commented Sep 1, 2024 • edited by ytmimi Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rufevean commented Sep 1, 2024

ding-young commented Sep 2, 2024

rufevean commented Sep 3, 2024

ytmimi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ytmimi Sep 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rufevean Sep 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rufevean commented Sep 4, 2024

ytmimi commented Sep 4, 2024

rufevean commented Sep 5, 2024 • edited Loading

ytmimi commented Sep 5, 2024

rufevean commented Sep 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ytmimi left a comment

Choose a reason for hiding this comment

rufevean commented Sep 9, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ytmimi Sep 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ytmimi Sep 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rufevean commented Sep 10, 2024

ytmimi left a comment

Choose a reason for hiding this comment

rufevean commented Sep 12, 2024

ytmimi commented Sep 12, 2024

rufevean commented Sep 12, 2024

ytmimi commented Sep 12, 2024

rufevean commented Sep 1, 2024 •

edited by ytmimi

Loading

ytmimi Sep 4, 2024 •

edited

Loading

rufevean Sep 7, 2024 •

edited

Loading

rufevean commented Sep 5, 2024 •

edited

Loading

ytmimi Sep 9, 2024 •

edited

Loading

ytmimi Sep 10, 2024 •

edited

Loading