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

Allow Self::Module to be mutated. #58609

Merged
merged 2 commits into from
Feb 23, 2019
Merged

Conversation

gabi-250
Copy link
Contributor

This only changes &Self::Module to &mut Self::Module in a couple of places.

codegen_allocator and write_metadata from ExtraBackendMethods mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement codegen_allocator for my backend, and I need to be able to mutate Self::Module:

fn codegen_allocator(&self, tcx: TyCtxt, mods: &Self::Module, kind: AllocatorKind);

Modifying the module in codegen_allocator/write_metadata is not a problem for the LLVM backend, because ModuleLlvm contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and unsafe as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?

`codegen_allocator` and `write_metadata` mutate the underlying LLVM module. As
such, it makes sense for these two functions to receive a mutable reference to
the module (as opposed to an immutable one).
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @zackmdavis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 20, 2019
@zackmdavis
Copy link
Member

With regrets, I don't think I'm the most qualified reviewer for this. Maybe ...

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned zackmdavis Feb 20, 2019
Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rationale is that the llvm backend actually does mutate some state in

let llfn = llvm::LLVMRustGetOrInsertFunction(llmod,

via

http://llvm.org/doxygen/classllvm_1_1Module.html#abb107e4edbf05eae92936cba6801c2d9

Same with write_metadata:

pub fn write_metadata<'a, 'gcx>(

The rabbit hole goes even deeper than that, we should probably start giving functions like

pub fn LLVMAddGlobal(M: &'a Module, Ty: &'a Type, Name: *const c_char) -> &'a Value;
&mut arguments.

) -> EncodedMetadata {
base::write_metadata(tcx, metadata)
}
fn codegen_allocator(&self, tcx: TyCtxt, mods: &ModuleLlvm, kind: AllocatorKind) {
fn codegen_allocator(&self, tcx: TyCtxt, mods: &mut ModuleLlvm, kind: AllocatorKind) {
unsafe { allocator::codegen(tcx, mods, kind) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please change the codegen function to also take a &mut ModuleLlvm

@@ -120,11 +120,11 @@ impl ExtraBackendMethods for LlvmCodegenBackend {
fn write_metadata<'b, 'gcx>(
&self,
tcx: TyCtxt<'b, 'gcx, 'gcx>,
metadata: &ModuleLlvm
metadata: &mut ModuleLlvm
) -> EncodedMetadata {
base::write_metadata(tcx, metadata)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

write_metadata should also take &mut ModuleLlvm to properly signal the mutability.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

cc @irinagpopa

@eddyb
Copy link
Member

eddyb commented Feb 21, 2019

So the explanation for the FFI signatures (which should've probably been left in a comment somewhere) is that:

  • &Foo is a shared (mutable) reference
  • &'a mut Foo<'a> is an "owning" reference

The safe APIs can be changed freely as long as the FFI signatures don't need to be adjusted.

@gabi-250
Copy link
Contributor Author

@eddyb @oli-obk Thank you for reviewing this!

I've addressed your comments in my last commit.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

@bors r+

Thanks!

@bors
Copy link
Contributor

bors commented Feb 21, 2019

📌 Commit e5d1fa5 has been approved by oli-obk

@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 Feb 21, 2019
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Allow Self::Module to be mutated.

This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.

`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
https://github.com/rust-lang/rust/blob/f66e4697ae286985ddefc53c3a047614568458bb/src/librustc_codegen_ssa/traits/backend.rs#L41
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Allow Self::Module to be mutated.

This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.

`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
https://github.com/rust-lang/rust/blob/f66e4697ae286985ddefc53c3a047614568458bb/src/librustc_codegen_ssa/traits/backend.rs#L41
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Allow Self::Module to be mutated.

This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.

`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
https://github.com/rust-lang/rust/blob/f66e4697ae286985ddefc53c3a047614568458bb/src/librustc_codegen_ssa/traits/backend.rs#L41
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Allow Self::Module to be mutated.

This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.

`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
https://github.com/rust-lang/rust/blob/f66e4697ae286985ddefc53c3a047614568458bb/src/librustc_codegen_ssa/traits/backend.rs#L41
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
Centril added a commit to Centril/rust that referenced this pull request Feb 23, 2019
Allow Self::Module to be mutated.

This only changes `&Self::Module` to `&mut Self::Module` in a couple of places.

`codegen_allocator` and `write_metadata` from `ExtraBackendMethods` mutate the underlying LLVM module. As such, it makes sense for these two functions to receive a mutable reference to the module (as opposed to an immutable one).

I am trying to implement `codegen_allocator` for my backend, and I need to be able to mutate `Self::Module`:
https://github.com/rust-lang/rust/blob/f66e4697ae286985ddefc53c3a047614568458bb/src/librustc_codegen_ssa/traits/backend.rs#L41
Modifying the module in `codegen_allocator`/`write_metadata` is not a problem for the LLVM backend, because [ModuleLlvm](https://github.com/rust-lang/rust/blob/master/src/librustc_codegen_llvm/lib.rs#L357) contains a raw pointer to the underlying LLVM module, so it can easily be mutated through FFI calls.

I am trying to avoid interior mutability and `unsafe` as much as I can. What do you think? Does this change make sense, or is there a reason why this should stay the way it is?
bors added a commit that referenced this pull request Feb 23, 2019
Rollup of 16 pull requests

Successful merges:

 - #58100 (Transition librustdoc to Rust 2018)
 - #58122 (RangeInclusive internal iteration performance improvement.)
 - #58199 (Add better error message for partial move)
 - #58227 (Updated RELEASES.md for 1.33.0)
 - #58353 (Check the Self-type of inherent associated constants)
 - #58453 (SGX target: fix panic = abort)
 - #58476 (Remove `LazyTokenStream`.)
 - #58526 (Special suggestion for illegal unicode curly quote pairs)
 - #58595 (Turn duration consts into associated consts)
 - #58609 (Allow Self::Module to be mutated.)
 - #58628 (Optimise vec![false; N] to zero-alloc)
 - #58643 (Don't generate minification variables if minification disabled)
 - #58648 (Update tests to account for cross-platform testing and miri.)
 - #58654 (Do not underflow after resetting unmatched braces count)
 - #58658 (Add expected/provided byte alignments to validation error message)
 - #58667 (Reduce Miri-related Code Repetition `like (n << amt) >> amt`)

Failed merges:

r? @ghost
@bors bors merged commit e5d1fa5 into rust-lang:master Feb 23, 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.

6 participants