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

Clean up ModuleConfig initialization #70644

Merged
merged 3 commits into from
Apr 12, 2020

Conversation

nnethercote
Copy link
Contributor

Because it's currently a mess.

r? @Mark-Simulacrum

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 1, 2020
The condition checks if `sess.opts.output_types` doesn't contain
`OutputType::Assembly` within a match arm that is only reached if
`sess.opts.output_types` contains `OutputType::Assembly`.
@nnethercote
Copy link
Contributor Author

The middle commit is difficult to review, apologies for that. Note that the old set_flags function is called for all three of the configs, so that's a tidbit that makes reading the commit a bit easier.

There are three `ModuleConfigs`, one for each `ModuleKind`. The code to
initialized them is spaghetti imperative code that sets each field to a
default value and then modifies many fields in complicated ways. This
makes it very hard to tell what value ends up in each field in each
config.

For example, the `modules_config.emit_pre_lto_bc` field is set twice,
which means it can be set to true and then incorrectly set back to
false. (This probably hasn't been noticed because it happens in a very
obscure case.)

This commit changes the code to a declarative style in which
`ModuleConfig::new` initializes all fields and then they are never
changed again. This is slightly more concise and much easier to read.
(And it fixes the abovementioned `emit_pre_lto_bc` error as well.)
That way it matches `ModuleKind::Regular`.
@joelpalmer joelpalmer added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 9, 2020
@Mark-Simulacrum
Copy link
Member

@bors r+

Thanks! The code is much better now, even if still a bit confusing, but I think that's fairly unavoidable for this sort of thing.

@bors
Copy link
Contributor

bors commented Apr 11, 2020

📌 Commit 5131c69 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 11, 2020
Centril added a commit to Centril/rust that referenced this pull request Apr 11, 2020
…nit, r=Mark-Simulacrum

Clean up `ModuleConfig` initialization

Because it's currently a mess.

r? @Mark-Simulacrum
@bors
Copy link
Contributor

bors commented Apr 11, 2020

⌛ Testing commit 5131c69 with merge 071b3426de7f4a0c693aca72266c4ebcdbfcecdd...

@Dylan-DPC-zz
Copy link

@bors retry yield

bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 11, 2020
Rollup of 5 pull requests

Successful merges:

 - rust-lang#70644 (Clean up `ModuleConfig` initialization)
 - rust-lang#70937 (Fix staticlib name for *-pc-windows-gnu targets)
 - rust-lang#70996 (Add or_insert_with_key to Entry of HashMap/BTreeMap)
 - rust-lang#71020 (Store UNICODE_VERSION as a tuple)
 - rust-lang#71021 (Use write!-style syntax for MIR assert terminator)

Failed merges:

r? @ghost
@bors bors merged commit f9c0ea2 into rust-lang:master Apr 12, 2020
@nnethercote nnethercote deleted the clean-up-ModuleConfig-init branch April 12, 2020 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants