-
Notifications
You must be signed in to change notification settings - Fork 14
Merge changes into upstream Rust #29
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
Comments
From #27:
If I understand correctly:
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. |
So it seems like we should be more-or-less good to go in that area. |
Have raised rust-lang#44052 to see what the Rust folks think. |
A list of bugfixes to be upstreamed is at #116. |
This issue is for discussion on upstreaming AVR support to upstream Rust.
Things we need to do first
libcore
library (open issues)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.The text was updated successfully, but these errors were encountered: