-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
No more target.target #77943
No more target.target #77943
Conversation
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
c4dcf4b
to
45d6190
Compare
r? @petrochenkov |
@@ -307,7 +307,7 @@ pub struct CodegenContext<B: WriteBackendMethods> { | |||
pub allocator_module_config: Arc<ModuleConfig>, | |||
pub tm_factory: TargetMachineFactory<B>, | |||
pub msvc_imps_needed: bool, | |||
pub target_pointer_width: String, | |||
pub target_pointer_width: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we only allow/support pointer size of 16/32/64. I prefer to encode this
to an enum instead to avoid mistaken typo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've considered an enum, and think that #77604 is a good idea, but in this instance a number feels more natural to me.
-
Enums have to be imported, which causes overhead. Most of the present enums in the spec module are on the optional
TargetOptions
structure, so only have to imported by the few targets that specify those options. @petrochenkov 's PR moves the only enum currently imported by all target filesLinkerFlavor
intoTargetOptions
. -
Ideally one would have
PointerWidth::16
or something, but identifiers can't start width digits, so it'd bePointerWidth::W16
or something, which isn't pleasant IMO. -
Many places in the compiler assume the values to be integers already, some also do comparisons with other widths specified.
That being said, there are advantages of enums, main one is that one can build exhaustive matches throughout the compiler, and that it's immediately clear that only 16,32,64 bits are supported.
Didn't know about your PR, sorry. I've searched the PRs for Have you done your PR with automatic tools, or more manually? If the latter is the case, I'd suggest to merge this PR after yours, because it's quite easy for me to rebase thanks to having automated the large diff causing changes.
That's a good point. Will do it. 👍 |
Rebasing shouldn't be a problem here, we can land this PR first. |
45d6190
to
60ba8e7
Compare
Also change target_pointer_width to pointer_width. Preparation for a subsequent type change of target_pointer_width to an integer together with a rename to pointer_width. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/rustc_target/src/spec/ -type f -exec sed -i -e 's/target_pointer_width: "\(.*\)"\..*,/pointer_width: \1,/g' {} \;
Rename target_pointer_width to pointer_width because it is already member of the Target struct. The compiler supports only three valid values for target_pointer_width: 16, 32, 64. Thus it can safely be turned into an int. This means less allocations and clones as well as easier handling of the type.
…inter_width Preparation for a subsequent change that replaces rustc_target::config::Config with its wrapped Target. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/ -type f -exec sed -i -e 's/target\.target\([)\.,; ]\)/target\1/g' {} \; find compiler/ -type f -exec sed -i -e 's/target\.target$/target/g' {} \; find compiler/ -type f -exec sed -i -e 's/target.ptr_width/target.pointer_width/g' {} \; ./x.py fmt
The wrapper type led to tons of target.target across the compiler. Its ptr_width field isn't required any more, as target_pointer_width is already present in parsed form.
60ba8e7
to
d683e3a
Compare
@bors r+ p=10 (conflict-prone) |
📌 Commit d683e3a has been approved by |
☀️ Test successful - checks-actions, checks-azure |
Tested on commit rust-lang/rust@b5c9e24. Direct link to PR: <rust-lang/rust#77943> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @eddyb @RalfJung).
Replace target.target with target Fix fallout caused by rustc PR: rust-lang/rust#77943 Fixes rust-lang/rust#77988
…crum rustc_target: Move some target options from `Target` to `TargetOptions` The only reason for `Target` to `TargetOptions` to be separate structures is that options in `TargetOptions` have reasonable defaults and options in `Target` don't. (Otherwise all the options logically belong to a single `Target` struct.) This PR moves a number of options with reasonable defaults from `Target` to `TargetOptions`, so they no longer needs to be specified explicitly for majority of the targets. The move also allows to inherit the options from `rustc_target/src/spec/*_base.rs` files in a nicer way. I didn't change any specific option values here. The moved options are `target_c_int_width` (defaults to `"32"`), `target_endian` (defaults to `"little"`), `target_os` (defaults to `"none"`), `target_env` (defaults to `""`), `target_vendor` (defaults to `"unknown"`) and `linker_flavor` (defaults to `LinkerFlavor::Gcc`). Next steps (in later PRs): - Find a way to merge `TargetOptions` into `Target` - If not, always access `TargetOptions` fields through `Deref` making it a part of `Target` at least logically (`session.target.target.options.foo` -> `session.target.target.foo`) - ~Eliminate `session::config::Config` and use `Target` instead (`session.target.target.foo` -> `session.target.foo`)~ Done in rust-lang#77943. - Avoid tautologies in option names (`target.target_os` -> `target.os`) - Resolve _ rust-lang#77730 (rustc_target: The differences between `target_os = "none"` and `target_os = "unknown"`, and `target_vendor = "unknown"` and `target_vendor = ""` are unclear) noticed during implementation of this PR.
Two main changes of this PR:
target_pointer_width
into an integer and rename topointer_width
.The compiler only allowed three valid values for the width anyways.
An integer is more natural for this value, and saves a few allocations
and copies.
rustc_session::config::Config
wrapper and replace it withits inner member
Target
. Aka. no moretarget.target
. This makes life somuch easier, but it also causes a ton of downstream breakage.
Some changes of this PR were done using tooling. These tooling-made changes
were isolated to their own commits to make review easier.
It's best to review the PR commit-by-commit.
Miri PR: rust-lang/miri#1583
I request p=10 bors priority because of the breakage.