rebase rust llvm patches on top of llvm HEAD #3628
Conversation
|
The first time the mac bots built this they hit an error in compiler-rt: http://bot.rust-lang.org/logs/2012/08/29/2012-09-29T21:41:42Z-4dfd5aad-c1c2-42c6-a87a-d4dd89013281.html Second time built fine |
|
So far I haven't gotten it to build on windows http://bot.rust-lang.org/logs/2012/08/30/2012-09-30T00:20:09Z-7de50d1b-c50e-45e6-ab36-d4576d1c669d.html |
|
Oh, i deleted the workspace on the wrong bot while I was testing. windows is probably fine. |
two closures in the same function body can end up having the same mangled name. This small patch uses gensym to uniquely name each closure body so there won't be conflicts.
|
I'm feeling confident about the branch that's on try now. I want to see the window bot go green though. |
|
I just realized I forgot to update compiler-rt. Didn't seem to be an issue on my mac, but maybe it was causing problems for windows. I just updated this request to include it. It depends on brson/llvm#4 before it can land though. |
|
Pushed to both try and try2. try is showing a mysterious test failure on windows (on yesterday's push) |
|
I suspect that failure on windows is preexisting since the 'try' branch runs the 'check-lite' target that the windows bots don't usually run. |
|
Merged1 |
Fix is_subpath
add back some tokio features Turns out I went a bit too fer when I removed features, so `socketpair` was no longer used.
This fixes #3142, and depends on brson/llvm#3 being accepted. Along the way I found a particularly interesting bug. Two closures in a method shared the same mangled name, which caused a rather confusing collision. I solved this by changing
trans_expr_fnto usemangle_internal_name_by_path_and_seq, but to be perfectly honest, I have no idea why we never hit this before.