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 11 pull requests #42257

Closed
wants to merge 26 commits into from

Conversation

jorendorff and others added 26 commits May 19, 2017 13:43
It was decided in the RFC discussion rust-lang/rfcs#1954 to make the function call syntax Rc::clone(&foo) the idiomatic way to clone a reference counted pointer (over the method call syntax foo.clone(). This change updates the documentation of Rc, Arc and their respoective Weak pointers to reflect it and bring more exposure to the existence of the function call syntax.
Generally useful, but also a prerequisite for moving a bunch of unit tests off Range::step_by.
This should include a fix for rust-lang/cargo#4091 with an updated version of
libgit2.

Closes rust-lang/cargo#4091
trace_macro: Show both the macro call and its expansion. rust-lang#42072.

See rust-lang#42072 for the initial motivation behind this.

The change is not the minimal fix, but I want this behavior almost every time I use `trace_macros`.
Update to Rc and Arc documentation to favor the Rc::clone(&ptr) syntax.

This is a followup of the discussion in rust-lang/rfcs#1954.

The solution chosen by the core team to address the problem tackled by the [the RFC](rust-lang/rfcs#1954) was to make the function call syntax Rc::clone(&foo) the idiomatic way to clone a reference counted pointer (over the method call syntax foo.clone()).
This change updates the documentation of Rc, Arc and their respective Weak pointers to reflect this decision and bring more exposure to the existence of the function call syntax.
Stabilize non capturing closure to fn coercion

Stabilisation PR for non capturing closure to fn coercion.

closes rust-lang#39817
…excrichton

Override size_hint and propagate ExactSizeIterator for iter::StepBy

Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`.

A small non-breaking subset of rust-lang#42110 (which I closed).

Includes two small documentation changes @ivandardi requested on that PR.

r? @alexcrichton
…x-1, r=nikomatsakis

incr.comp.: Track expanded spans instead of FileMaps.

This PR removes explicit tracking of FileMaps in response to rust-lang#42101. The reasoning behind being able to just *not* track access to FileMaps is similar to why we don't track access to the `DefId->DefPath` map:
1. One can only get ahold of a `Span` value by accessing the HIR (for local things) or a `metadata::schema::Entry` (for things from external crates).
2. For both of these things we compute a hash that incorporates the *expanded spans*, that is, what we hash is in the (FileMap independent) format `filename:line:col`.
3. Consequently, everything that emits a span should already be tracked via its dependency to something that has the span included in its hash and changes would be detected via that hash.

One caveat here is that we have to be conservative when exporting things in metadata. A crate can be built without debuginfo and would thus by default not incorporate most spans into the metadata hashes. However, a downstream crate can make an inline copy of things in the upstream crate and span changes in the upstream crate would then go undetected, even if the downstream uses them (e.g. by emitting debuginfo for an inlined function). For this reason, we always incorporate spans into metadata hashes for now (there might be more efficient ways to handle this safely when red-green tracking is implemented).

r? @nikomatsakis
…eddyb

Remove all instances of fragment_infos and fragment sets

Remove unused fragment structs. This was suggested by @eddyb in IRC: [botbot link](https://botbot.me/mozilla/rustc/2017-05-23/?msg=86016574&page=2).
rust-src: include everything needed to compile libstd with jemalloc

I am not very happy about all this `Path::new`, but did not find a nice way to avoid it. Also, this shouldn't be very performance-critical.

With this patch, rust-src-1.19.0-dev.tar.gz grows from 1.4 to 3.1 MiB (new uncompressed size: 15.5 MiB). Not great, but shipping incomplete sources is also not great, and this is still much smaller than pre-rust-lang#41546. Excluding the entire `src/jemalloc/test` does not work, unfortunately; there is a file in there that is needed to build libstd. (And anyway there's just 190 KiB uncompressed left in that folder.)

In principle, we could try excluding the Rust test suite directories (that would be `libcore/tests` and `libcollection/tests`). I don't know enough about how this component is used to judge whether that would cause any problems. Anyway this is just 600 KiB uncompressed.

Fixes rust-lang#41952
…ichton

use shared scripts for init and sccache in cross image

cc rust-lang#42201
cc @malbarbo
…tsakis

Updated locked version of libgit2

This should include a fix for rust-lang/cargo#4091 with an updated version of
libgit2.

Closes rust-lang/cargo#4091
…ed-tail, r=eddyb

extend `struct_tail` to operate over tuples

Not 100% sure why this got exposed when it wasn't before, but this struct definitely seems wrong.

Fixes rust-lang#42110

r? @eddyb
@rust-highfive
Copy link
Collaborator

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@Mark-Simulacrum
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented May 27, 2017

📌 Commit 818c0e2 has been approved by Mark-Simulacrum

@bors
Copy link
Contributor

bors commented May 27, 2017

🔒 Merge conflict

@bors
Copy link
Contributor

bors commented May 27, 2017

☔ The latest upstream changes (presumably #42109) made this pull request unmergeable. Please resolve the merge conflicts.

@Mark-Simulacrum Mark-Simulacrum deleted the rollup branch May 27, 2017 14:04
@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.