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

Make the lifetime parameters of tcx consistent. #58926

Merged
merged 1 commit into from
Mar 9, 2019

Conversation

gabi-250
Copy link
Contributor

@gabi-250 gabi-250 commented Mar 5, 2019

I have implemented codegen_allocator for my backend, but I've had to make a small change to its signature in ExtraBackendMethods. I wonder if this change is justified, or if it is too specific to my use case to be useful to anyone else.

write_metadata and codegen_allocator are both called from codegen_crate (in librustc_codegen_ssa/base.rs), and they both receive the same tcx as an argument:

let metadata = time(tcx.sess, "write metadata", || {
backend.write_metadata(tcx, &mut metadata_llvm_module)
});

and:

time(tcx.sess, "write allocator module", || {
backend.codegen_allocator(tcx, &mut modules, kind)
});

However, codegen_allocator accepts a TyCtxt with any lifetime parameters (tcx: TyCtxt<'_, '_, '_>), while write_metadata requires that the tcx argument is of type TyCtxt<'b, 'gcx, 'gcx>. In my implementation, I've found that it's necessary for tcx in codegen_allocator to also have the <'b, 'gcx, 'gcx> lifetime parameters.

Have I misunderstood the purpose of the parameters of TyCtxt? I've read here that the last two parameters only need to be distinct if the function needs to be used during type inference, but I don't think that is the case here.

@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 5, 2019
@petrochenkov
Copy link
Contributor

write_metadata doesn't seem to technically require the parameters to be the same, but I guess this is still the intent given the stage at which write_metadata works.
Then it seems reasonable to adjust codegen_allocator.

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 5, 2019

📌 Commit cd9a0cf has been approved by petrochenkov

@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 Mar 5, 2019
pietroalbini added a commit to pietroalbini/rust that referenced this pull request Mar 8, 2019
Make the lifetime parameters of tcx consistent.

I have implemented `codegen_allocator` for my backend, but I've had to make a small change to its signature in `ExtraBackendMethods`. I wonder if this change is justified, or if it is too specific to my use case to be useful to anyone else.

`write_metadata` and `codegen_allocator` are both called from `codegen_crate` (in `librustc_codegen_ssa/base.rs`), and they both receive the same `tcx` as an argument:

https://github.com/rust-lang/rust/blob/c196097e588b05e86b5ce6de992b2a6e6a7027bd/src/librustc_codegen_ssa/base.rs#L555-L557

and:

https://github.com/rust-lang/rust/blob/c196097e588b05e86b5ce6de992b2a6e6a7027bd/src/librustc_codegen_ssa/base.rs#L640-L642

However, `codegen_allocator` accepts a `TyCtxt` with any lifetime parameters (`tcx: TyCtxt<'_, '_, '_>`), while `write_metadata` requires that the `tcx` argument is of type `TyCtxt<'b, 'gcx, 'gcx>`. In my implementation, I've found that it's necessary for `tcx` in `codegen_allocator` to also have the `<'b, 'gcx, 'gcx>` lifetime parameters.

Have I misunderstood the purpose of the parameters of `TyCtxt`? I've read [here](https://rust-lang.github.io/rustc-guide/ty.html) that the last two parameters only need to be distinct if the function needs to be used during type inference, but I don't think that is the case here.
bors added a commit that referenced this pull request Mar 9, 2019
Rollup of 24 pull requests

Successful merges:

 - #58080 (Add FreeBSD armv6 and armv7 targets)
 - #58204 (On return type `impl Trait` for block with no expr point at last semi)
 - #58269 (Add librustc and libsyntax to rust-src distribution.)
 - #58369 (Make the Entry API of HashMap<K, V> Sync and Send)
 - #58861 (Expand where negative supertrait specific error is shown)
 - #58877 (Suggest removal of `&` when borrowing macro and appropriate)
 - #58883 (Suggest appropriate code for unused field when destructuring pattern)
 - #58891 (Remove stray ` in the docs for the FromIterator implementation for Option)
 - #58893 (race condition in thread local storage example)
 - #58906 (Monomorphize generator field types for debuginfo)
 - #58911 (Regression test for #58435.)
 - #58912 (Regression test for #58813)
 - #58916 (Fix release note problems noticed after merging.)
 - #58918 (Regression test added for an async ICE.)
 - #58921 (Add an explicit test for issue #50582)
 - #58926 (Make the lifetime parameters of tcx consistent.)
 - #58931 (Elide invalid method receiver error when it contains TyErr)
 - #58940 (Remove JSBackend from config.toml)
 - #58950 (Add self to mailmap)
 - #58961 (On incorrect cfg literal/identifier, point at the right span)
 - #58963 (libstd: implement Error::source for io::Error)
 - #58970 (delay_span_bug in wfcheck's ty.lift_to_tcx unwrap)
 - #58984 (Teach `-Z treat-err-as-bug` to take a number of errors to emit)
 - #59007 (Add a test for invalid const arguments)

Failed merges:

 - #58959 (Add release notes for PR #56243)

r? @ghost
@bors bors merged commit cd9a0cf into rust-lang:master Mar 9, 2019
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.

None yet

4 participants