| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Bases on commit to switch to libsyntax by @nrc
|
|
|
|
|
|
|
|
|
|
This API isn't fantastic, but it's the best I can come up with without
something like `concat_idents!()`. There are relatively few places where
config is set, to hopefully the ugliness isn't disastrous.
Change previous occurences of `config.item = value` to this new API,
rather than using `config.override_value()`. Undo the changes to
`override_value()`, as it's no longer important to propogate the error
to the caller. Add a test for the new interface.
|
|
Preparation for #865, which proposes adding a flag which outputs which
config options are used during formatting.
This PR should not make any difference to functionality. A lot of this
was search-and-replace.
Some areas worthy of review/discussion:
- The method for each config item returns a clone of the underlying
value. We can't simply return an immutable reference, as lots of
places in the code expect to be able to pass the returned value as
`bool` (not `&bool). It would be nice if the `bool` items could
return a copy, but the more complex types a borrowed reference... but
unfortunately, I couldn't get the macro to do this.
- A few places (mostly tests and `src/bin/rustfmt.rs`) were overriding
config items by modifying the fields of the `Config` struct directly.
They now use the existing `override_value()` method, which has been
modified to return a `Result` for use by `src/bin/rustfmt.rs`. This
benefits of this are that the complex `file_lines` and `write_mode`
strings are now parsed in one place (`Config.override_value`) instead
of multiple. The disadvantages are that it moves the compile-time
checks for config names to become run-time checks.
|
|
Better file_lines
|
|
|
|
|
|
|
|
|
|
Fixes #1450
Adds control_style option
|
|
|
|
|
|
|
|
|
|
Resolves #1335. Does not attempt to handle a `\r` not followed by a `\n` nor
attempt to handle Unicode intricacies (#6) including zero-width or multi-byte
characters.
|
|
|
|
|
|
Now follows struct_lit_style (and most other struct_lit_ options).
Required a fair bit of refactoring and bug fixes.
Fixes #1311
|
|
Also fixes a minor bug when we break a line after `if` and used to leave a trailing space
|
|
|
|
Add error_on_line_overflow option
|
|
|
|
|
|
Makes it configurable whether to error if unable to get all lines within
the max_width.
|
|
* New `disable_all_formatting` config option
* Resolve code review comments
|
|
|
|
Fixes #1229
Fixes #1277
|
|
(with current length and configured limit)
|
|
Lots of changes to how closures work
|
|
+ Cargo update
+ 0.6.2 release
|
|
|
|
This changes rustfmt to return exit code 4
when run with write mode diff and differences between
the formatted code and the original code are found.
Useful for CI to make sure your contributors actually ran rustfmt.
|
|
This commit adds a type to represent lines in files, and adds it to the
`Config` struct. It will be used for restricting formatting to specific
lines.
Refs #434
|
|
This commit adds a `codemap` module, and moves the `CodemapSpanUtils`
added in #857 to it. This is preparation for adding more `Codemap`
specific utilities.
Refs #434
|
|
|
|
* Handle pub(restricted)
This commit properly handles pub(restricted) as introduced in RFC 1422
[0]. The syntax support was added in #971, but they were not correctly
formatted.
[0] https://github.com/rust-lang/rfcs/blob/master/text/1422-pub-restricted.md
Fixes #970
* Drop #[inline] attribute on format_visibility
* Make newly non-failing functions return String
The change to `format_visibiilty` means that `format_header` and
`format_unit_struct` can no longer fail. Their return type is updated to
reflect that.
|
|
|
|
The old behaviour stored everything in memory until we were finished. Now we write as soon as we can.
This gives better behaviour when formatting large programs, since there is some progress indication. It also opens the door to optimising memory use by not storing everything in memory unless it is required (which it still might be). That is left as future work though.
|
|
|
|
|
|
Outputting child module contents in the "Plain" write mode does not make
sense, since there is no way to differentiate code that came from a
child module from that which came from the parent file.
|
|
Closes #915
Closes #930
Closes #931
|
|
|
|
|
|
This `if` was used to separate error output from the formatting output, when they both used stdout. It was useful for integration with tools, which can submit input to stdin and read pretty printed result from stdout without worrying about errors intermingled with the actual result.
But now we write errors to `stderr`, so the problem disappears and we can safely remove this `if`.
Errors should never pass silently, unless explicitly silenced.
|
|
|
