-
Notifications
You must be signed in to change notification settings - Fork 889
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
Better error message #6302
Comments
Great suggestion. I think it should be easy enough to add the file name to the error message. PRs are welcome! Lines 405 to 409 in 46cb7d3
|
hey, can you assign me this, i will work on this and update you |
I am thinking of something like this, let me know if i am wrong please, thank you |
@rufevean you can assign yourself by commenting Does the error provide methods to get the |
@rustbot claim |
i am getting error response like this, will this work?
please let me know if am doing something wrong , thank you |
There’s colour support in rustfmt correct? You could try adding them in line with the Rustc colour palette |
@rufevean no I don't think this will work. You can't assume that the The file path that we want to display should be available further up the call stack, It might make more sense to pass the complete path to the file down instead of the directory where the file is found. That should make it much easier to get the correct file. @appetrosyan yes there is support to display formatting errors with color, but I suspect it'll be a bit harder to add support for that in this case. IMO it'll be best to focus on the simpler problem, which is to enhance the error message to direct users to the config that rustfmt is failing to parse. Work to make the error message prettier can be done as a follow up. |
|
@rufevean I appreciate that you've continued to look into this. I don't think calling As your code demonstrates calling |
thank you for your patience, and by
you mean, directly taking file path as an arguement? and we want to point out the file rather than just the directory , right? because if its just the directory, we can acheive that by simple using |
Yes that's what I mean. I don't see why we couldn't change the code as follows: pub(crate) fn from_toml_for_style_edition(
toml: &str,
- dir: &Path,
+ file_path: &Path,
edition: Option<Edition>,
style_edition: Option<StyleEdition>,
version: Option<Version>,
) -> Result<Config, String> { |
i am getting this output
and as you suggested, i added file_path as an argument and also added that to other connecting functions wherever an error was occurring, and as the file_path is added i have simply displayed it with this code
|
@rufevean feel free to open a PR with the approach you've mentioned. I'll leave any additional comments there. |
hey, i have started a pull request but a major error occurred while running the tests, i have to add an argument of file_path everywhere config::from_toml() is invoked, adding an empty path is a viable approach or is there any better alternative? |
I don't think so. If you're changing the function signature then you also need to update all of the invocations. |
I ran into a problem that was resolved by looking at #2057. It took longer than I'd like and the error message is not too helpful.
Currently if the project doesn't have
rustfmt.toml
in the workspace,cargo fmt
checks all parent directories for a configuration file. This is not the expected behaviour, because as a user of Rust one assumes that going to the parent ends at the nearest workspace (and workspaces can't be nested). As such it is unclear which configuration file failed to parse.So, the error message that looks like this,
Should really read as more like this:
Ideally, of course the error message can be brought in line with the quality of
rustc
errors, looking more likeThe text was updated successfully, but these errors were encountered: