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

Rollup of 4 pull requests #41573

Closed
wants to merge 14 commits into from
Closed

Rollup of 4 pull requests #41573

wants to merge 14 commits into from

Conversation

bitshifter and others added 14 commits April 25, 2017 20:27
Some accesses in OperandPairs were missing. Fixes rust-lang#41479.
Didn't get around to removing all public access.
This requires copying out the cycle error to avoid a cyclic borrow.  Is
this a problem? Are there paths where we expect cycles to arise and not
result in errors? (In such cases, we could add a faster way to test for
cycle.)
…-map, r=eddyb

make *most* maps private

Currently we access the `DepTrackingMap` fields directly rather than using the query accessors. This seems bad. This branch removes several such uses, but not all, and extends the macro so that queries can hide their maps (so we can prevent regressions). The extension to the macro is kind of ugly :/ but couldn't find a simple way to do it otherwise (I guess I could use a nested macro...). Anyway I figure it's only temporary.

r? @eddyb
…ping, r=alexcrichton

Implement a file-path remapping feature in support of debuginfo and reproducible builds

This PR adds the `-Zremap-path-prefix-from`/`-Zremap-path-prefix-to` commandline option pair and is a more general implementation of rust-lang#41419. As opposed to the previous attempt, this implementation should enable reproducible builds regardless of the working directory of the compiler.

This implementation of the feature is more general in the sense that the re-mapping will affect *all* paths the compiler emits, including the ones in error messages.

r? @alexcrichton
Add missing OperandPair struct field index adjustments. Fixes rust-lang#41479.

This is a bug fix for a regression in rust-lang@6d841da.
@frewsxcv
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Apr 27, 2017

📌 Commit 4c725d2 has been approved by frewsxcv

@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 @nikomatsakis (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.

@bors
Copy link
Contributor

bors commented Apr 27, 2017

⌛ Testing commit 4c725d2 with merge 097d9bc...

@bors
Copy link
Contributor

bors commented Apr 27, 2017

💔 Test failed - status-travis

@aidanhs
Copy link
Member

aidanhs commented Apr 27, 2017

[00:21:06] warning: ../compiler-rt/lib/builtins/divdc3.c:21:1: warning: conflicting types for built-in function '__divdc3'
[00:21:06] warning:  __divdc3(double __a, double __b, double __c, double __d)
[00:21:06] warning:  ^
[00:21:06] warning: ../compiler-rt/lib/builtins/divsc3.c:21:1: warning: conflicting types for built-in function '__divsc3'
[00:21:06] warning:  __divsc3(float __a, float __b, float __c, float __d)
[00:21:06] warning:  ^
[00:21:06] warning: ../compiler-rt/lib/builtins/muldc3.c:21:1: warning: conflicting types for built-in function '__muldc3'
[00:21:06] warning:  __muldc3(double __a, double __b, double __c, double __d)
[00:21:06] warning:  ^
[00:21:06] warning: ../compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function '__mulsc3'
[00:21:06] warning:  __mulsc3(float __a, float __b, float __c, float __d)
[00:21:06] warning:  ^
[00:21:13] error: internal compiler error: /checkout/src/librustc_typeck/check/mod.rs:680: can't type-check body of DefId { krate: CrateNum(0), node: DefIndex(2147484335) => core/31cda99d85f5f93f25d91c8ad10a555f::intrinsics[0]::[0]::atomic_cxchg[0] }
[00:21:13]   --> /checkout/src/libcore/intrinsics.rs:67:5
[00:21:13]    |
[00:21:13] 67 |     pub fn atomic_cxchg<T>(dst: *mut T, old: T, src: T) -> (T, bool);
[00:21:13]    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[00:21:13] 
[00:21:13] note: the compiler unexpectedly panicked. this is a bug.
[00:21:13] 

Seems legit

@aidanhs
Copy link
Member

aidanhs commented Apr 27, 2017

Unsure which PR that was from after a quick look (even if I was I don't know how to create a rollup), so all of the individual PRs are still queued (retried after appveyor network failures).

(particularly odd is that each of the PRs passed the travis PR check)

@arielb1 arielb1 closed this Apr 27, 2017
@frewsxcv frewsxcv deleted the rollup branch April 27, 2017 12:59
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants