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

Merge changes into upstream Rust #29

Open
1 of 2 tasks
dylanmckay opened this issue Apr 25, 2017 · 4 comments
Open
1 of 2 tasks

Merge changes into upstream Rust #29

dylanmckay opened this issue Apr 25, 2017 · 4 comments

Comments

@dylanmckay
Copy link
Member

dylanmckay commented Apr 25, 2017

This issue is for discussion on upstreaming AVR support to upstream Rust.

Things we need to do first

One thing that I am concerned about is how hard it is going to be in order to add avr-llvm patches in order to fix codegen bugs - if AVR support is in Rust master, we will have to get AVR backend patches into the Rust LLVM fork. This may cause us to have longish periods of time where a single bug stops all users from using AVR.

@shepmaster
Copy link
Member

From #27:

Will targeting trunk cause troubles to try and get the patches into Rust's LLVM?

I'm not entirely sure to be honest. I'd really like it if we could just cherry-pick changes into Rust's LLVM. That should be alright because the changes will get picked up anyway when we upgrade LLVM next.

The only problem is that I'm not sure if we can do that - we're supposed to be tracking emscripten's version of LLVM so I'm not sure what the Rust team think about adding more patches into the fork. I guess there is already going to be all the Rust-specific LLVM patches in there.

If I understand correctly:

  • Emscripten has forked off from LLVM 4.0
  • Rust has forked off from Emscripten

If patches are submitted to LLVM trunk, then at some point, the relevant base code will have diverged and cherry-picks into 4.0 will start to accumulate conflicts. If patches are submitted to LLVM 4.0, then the same thing can happen in reverse (or the patches get lost, which would be worse). The only real solution there is to make sure that Rust / Emscripten continue to track LLVM trunk, which seems not-fully-likely.

Then there's the question of "will Rust accept AVR-specific patches to the Rust LLVM fork". I'll try and ask my contacts to see what they think.

@shepmaster
Copy link
Member

09:51 < acrichto> shep: we don't really have a policy around llvm upgrades right now
09:51 < acrichto> but historically
09:51 < acrichto> a) backports of merged patches are totally fine
09:52 < acrichto> b) upgrades to llvm HEAD are also ok if they pass tests

So it seems like we should be more-or-less good to go in that area.

@dylanmckay
Copy link
Member Author

Have raised rust-lang#44052 to see what the Rust folks think.

@dylanmckay
Copy link
Member Author

A list of bugfixes to be upstreamed is at #116.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants