Rollup of 10 pull requests #42258
Closed
Rollup of 10 pull requests #42258
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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).
…ulacrum regression test for rust-lang#39974 closes rust-lang#39974 r? @Mark-Simulacrum
…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
Allow variadic functions with cdecl calling convention. Fixes rust-lang#40244.
…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
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=10 |
|
📌 Commit 7ffeb85 has been approved by |
|
💔 Test failed - status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
struct_tailto operate over tuples #42251