Skip to content

config: Introduce a mergeable config #801

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 3 commits into from
Closed

config: Introduce a mergeable config #801

wants to merge 3 commits into from

Conversation

kamalmarhubi
Copy link
Contributor

This pull request introduces a mergeable config abstraction, and uses it for the verbose and skip_children configuration options.

@kamalmarhubi
Copy link
Contributor Author

@nrc, this is much nicer than #795 imo :-)

@kamalmarhubi kamalmarhubi mentioned this pull request Feb 2, 2016
Closed
@kamalmarhubi kamalmarhubi force-pushed the mergeable-config branch 2 times, most recently from 8894c3d to c673723 Compare February 2, 2016 16:59
@kamalmarhubi
config: Introduce a mergeable config
b483f4c 
This commit replaces `ParsedConfig` with a `PartialConfig` that can be
merged into a `Config` or another `PartialConfig`. This provides a
unified place for configuration that is passed through rustfmt, and a
mechanism for overriding settings from other sources.

Expected uses:
 - overriding config file options from command line options
 - adding options that do not make sense in the config file, such as
   line ranges to restrict formatting to; see rust-lang#434

refs rust-lang#434
@kamalmarhubi
config: Use PartialConfig for verbose and skip_children
9e98191
@kamalmarhubi
config: Use PartialConfig for write_mode
64e59e8 
This changes the handling of `write_mode` to use `PartialConfig` and
`Config::merge()` for overriding, and to no longer thread it through the
formatting code as a separate parameter.
@nrc
Copy link
Member

nrc commented Feb 3, 2016

What is the advantage of using a PartialConfig over just initialising a regular Config with the defaults and then overriding them?

@kamalmarhubi
Copy link
Contributor Author

Part of the motivation was to tidy up how write_mode is passed around and dealt wtih. I realise I didn't put up that change; pushed it up in case you want to see it.

On reflection I don't feel too strongly about this change, so it's up to you. The write_mode setting is kind of overloaded in a way that this doesn't fix anyway.

@kamalmarhubi
Copy link
Contributor Author

Anyway, feel free to look over the changes moving write_mode to only come from Config. I'll hold off fixing conflicts till I hear something positive / negative about the change. Thanks!

@kamalmarhubi
Copy link
Contributor Author

(I think I was refactoring as a way to understand code here.)

@nrc
Copy link
Member

nrc commented Feb 4, 2016

So, having the write mode be part of the config sounds like a good change. However, I don't see that using the builder pattern for the config is a pre-req for it. Maybe I'm missing something, but couldn't you just set it to some default and then reset it later in the right places?

@kamalmarhubi
Copy link
Contributor Author

Yeah, the config stuff isn't necessary. I'll send another PR tomorrow that gets the write_mode read solely from the config.

@kamalmarhubi
Copy link
Contributor Author

#812 replaces this.

@kamalmarhubi kamalmarhubi mentioned this pull request Apr 26, 2016
Closed
@kamalmarhubi kamalmarhubi mentioned this pull request May 30, 2016
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@kamalmarhubi @nrc