jiebi/CodeConvo huggingface dataset:
Code change:
"Cousins" of borrowed union sub-fields (and their further children) are not marked as borrowed.
This is , though I sort of thought we had tried to fix this.
I'm tagging this as WG-compiler-nll; I think it's something we should fix there.
For the sake of potential testsuite additions: this also should not compile with a simultaneous borrow of and .
I'll take a look at this one.
I'm not really sure what the bug is here, but I can explain what I think should be happening. This function: is responsible for determining when two values overlap. I expect us to say that two fields from a union are always considered to potentially overlap. In this case, and would be considered to overlap. Specifically, comparing those two fields would return : This is the code that I think should be responsible for doing that: It already looks a little fishy to me; in particular, it is returning if is a union, but I guess it should be equally true if is a union. Anyway, something here seems to be going awry!
So it seems like I forgot about how smart the compiler is now. This version of the test does error, as expected:
I think the policy is that we will keep this bug open, but file it under
(Since it is only fixed when NLL is enabled)
should this be ?
Note that to get an NLL test failure, you have to use after declaring :
NLL (migrate mode) is enabled in all editions as of PR . The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.

Related discussion:
text: <ins> error[E0502]: cannot borrow `u.z.c` as immutable because it is also borrowed as mutable --> $DIR/issue-45157.rs:37:20 | 34 |         let mref = &mut u.s.a; |                    ---------- mutable borrow occurs here ... 37 |         let nref = &u.z.c; |                    ^^^^^^ immutable borrow occurs here error[E0502]: cannot borrow `u.s.a` as mutable because it is also borrowed as immutable --> $DIR/issue-45157.rs:39:27 | 37 |         let nref = &u.z.c; |                    ------ immutable borrow occurs here 38 |         //~^ ERROR cannot borrow `u.z.c` as immutable because it is also borrowed as mutable [E0502] 39 |         println!("{} {}", mref, nref) |                           ^^^^ mutable borrow occurs here error: aborting due to 2 previous errors </ins>
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: [[package]] name = "bitflags" <del> version = "0.8.2" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "bitflags" </del> version = "0.9.1" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: [[package]] name = "pulldown-cmark" <del> version = "0.0.14" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "pulldown-cmark" </del> version = "0.0.15" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: "env_logger 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", "html-diff 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)", <del> "pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)", </ins> ] [[package]]
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: "checksum backtrace 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "99f2ce94e22b8e664d95c57fff45b98a966c2252b60691d0b7aeeccd88d70983" "checksum backtrace-sys 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "c63ea141ef8fdb10409d0f5daf30ac51f84ef43bff66f16627773d2a292cd189" "checksum bitflags 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "aad18937a628ec6abcd26d1489012cc0e18c21798210f491af69ded9b881106d" <del> "checksum bitflags 0.8.2 (registry+https://github.com/rust-lang/crates.io-index)" = "1370e9fc2a6ae53aea8b7a5110edbd08836ed87c88736dfabccade1c2b44bff4" </del> "checksum bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4efd02e230a02e18f92fc2735f44597385ed02ad8f831e7c1c1156ee5e1ab3a5" "checksum bitflags 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f5cde24d1b2e2216a726368b2363a273739c91f4e3eb4e0dd12d672d396ad989" "checksum bufstream 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "f2f382711e76b9de6c744cc00d0497baba02fb00a787f088c879f01d09468e32"
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: "checksum precomputed-hash 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "cdf1fc3616b3ef726a847f2cd2388c646ef6a1f1ba4835c2629004da48184150" "checksum procedural-masquerade 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "c93cdc1fb30af9ddf3debc4afbdb0f35126cbd99daa229dd76cdd5349b41d989" "checksum psapi-sys 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "abcd5d1a07d360e29727f757a9decb3ce8bc6e0efa8969cfaad669a8317a2478" <del> "checksum pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)" = "d9ab1e588ef8efd702c7ed9d2bd774db5e6f4d878bb5a1a9f371828fbdff6973" </del> "checksum pulldown-cmark 0.0.15 (registry+https://github.com/rust-lang/crates.io-index)" = "378e941dbd392c101f2cb88097fa4d7167bc421d4b88de3ff7dbee503bc3233b" "checksum pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a656fdb8b6848f896df5e478a0eb9083681663e37dcb77dd16981ff65329fe8b" "checksum quick-error 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "eda5fe9b71976e62bc81b781206aaa076401769b2143379d3eb2118388babac4"
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: [dependencies] env_logger = { version = "0.4", default-features = false } log = "0.3" <del> pulldown-cmark = { version = "0.0.14", default-features = false } </del> <ins> pulldown-cmark = { version = "0.1.0", default-features = false } </ins> html-diff = "0.0.4" [build-dependencies]
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: match self.inner.next() { Some(Event::FootnoteReference(ref reference)) => { let entry = self.get_entry(&reference); <del> let reference = format!("<sup id="supref{0}"><a href="#ref{0}">{0} </del> <ins> let reference = format!("<sup id="fnref{0}"><a href="#fn{0}">{0} </ins> </a></sup>", (*entry).1); return Some(Event::Html(reference.into()));
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: v.sort_by(|a, b| a.1.cmp(&b.1)); let mut ret = String::from("<div class="footnotes"><hr><ol>"); for (mut content, id) in v { <del> write!(ret, "<li id="ref{}">", id).unwrap(); </del> <ins> write!(ret, "<li id="fn{}">", id).unwrap(); </ins> let mut is_paragraph = false; if let Some(&Event::End(Tag::Paragraph)) = content.last() { content.pop();
Code change:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes

Related discussion:
text: } html::push_html(&mut ret, content.into_iter()); write!(ret, <del> "&nbsp;<a href="#supref{}" rev="footnote">↩</a>", </del> <ins> "&nbsp;<a href="#fnref{}" rev="footnote">↩</a>", </ins> id).unwrap(); if is_paragraph { ret.push_str("</p>");
Code change:
Hey, I'm curious about the . From what I understand: this works because Path is a single member struct containing only the type it's being reinterpreted as. My original question on #rust IRC was: Is this always guaranteed to be correct (in Rust) in terms of memory layout? The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs. I would love some clarification if this usage is correct or to what degree it is not. I'd also suggest we add clarification around this case with comments or support functions to aid future spelunking into std.
No, strictly speaking, this is not safe without .
excellent, thank you! The seems to indicate things going slowly. Adding a comment might still be a good idea for now. Reading the RFC, it mentions at least ARM64 where there might be layout differences. But according to , std shows up as supported as a Tier 2 platform. This implies that at least for now, this pattern in this instance () works. Is this correct?
That ARM64 issue seems to be related to calling convention, not memory layout, so it's not an issue here.
This is my understanding as well. I believe it is safe with either repr(transparent) or repr(C), the latter of which is stable. The  crate is a generalization of this safe cast.

Related discussion:
text: } // See note at the top of this module to understand why these are used: <ins> // // These casts are safe as OsStr is internally a wrapper around [u8] on all // platforms. // // Note that currently this relies on the special knowledge that libstd has; // these types are single-element structs but are not marked repr(transparent) // or repr(C) which would make these casts allowable outside std. </ins> fn os_str_as_u8_slice(s: &OsStr) -> &[u8] { unsafe { &*(s as *const OsStr as *const [u8]) } }
Code change:
The benchmarks for LinearMap and TreeMap should just be using the Map trait, but I encountered a strange borrow checking issue: diff: error: This seems like a borrowck bug, but I'm not sure. The same issue occurs when trying to work around it with a trait like with a method.

Related discussion:
text: <del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //
Code change:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

Related discussion:
text: /// Simple usage: /// /// ``` <del> /// #![feature(box_leak)] /// </del> /// fn main() { ///     let x = Box::new(41); ///     let static_ref: &'static mut usize = Box::leak(x);
Code change:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

Related discussion:
text: /// Unsized data: /// /// ``` <del> /// #![feature(box_leak)] /// </del> /// fn main() { ///     let x = vec![1, 2, 3].into_boxed_slice(); ///     let static_ref = Box::leak(x);
Code change:
Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.

Related discussion:
text: ///     assert_eq!(*static_ref, [4, 2, 3]); /// } /// ``` <del> #[unstable(feature = "box_leak", reason = "needs an FCP to stabilize", issue = "46179")] </del> <ins> #[stable(feature = "box_leak", since = "1.26.0")] </ins> #[inline] pub fn leak<'a>(b: Box<T>) -> &'a mut T where
Code change:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

Related discussion:
text: return; } <ins> let (_, line_hi, col_hi) = match ctx.byte_pos_to_line_and_col(span.hi) { Some(pos) => pos, None => { Hash::hash(&TAG_INVALID_SPAN, hasher); span.ctxt.hash_stable(ctx, hasher); return; } }; </ins> Hash::hash(&TAG_VALID_SPAN, hasher); // We truncate the stable ID hash and line and column numbers. The chances // of causing a collision this way should be minimal. Hash::hash(&(file_lo.name_hash as u64), hasher); <del> let col = (col_lo.0 as u64) & 0xFF; let line = ((line_lo as u64) & 0xFF_FF_FF) << 8; let len = ((span.hi - span.lo).0 as u64) << 32; let line_col_len = col | line | len; Hash::hash(&line_col_len, hasher); </del> <ins> // Hash both the length and the end location (line/column) of a span. If we // hash only the length, for example, then two otherwise equal spans with // different end locations will have the same hash. This can cause a problem // during incremental compilation wherein a previous result for a query that // depends on the end location of a span will be incorrectly reused when the // end location of the span it depends on has changed (see issue #74890). A // similar analysis applies if some query depends specifically on the length // of the span, but we only hash the end location. So hash both. let col_lo_trunc = (col_lo.0 as u64) & 0xFF; let line_lo_trunc = ((line_lo as u64) & 0xFF_FF_FF) << 8; let col_hi_trunc = (col_hi.0 as u64) & 0xFF << 32; let line_hi_trunc = ((line_hi as u64) & 0xFF_FF_FF) << 40; let col_line = col_lo_trunc | line_lo_trunc | col_hi_trunc | line_hi_trunc; let len = (span.hi - span.lo).0; Hash::hash(&col_line, hasher); Hash::hash(&len, hasher); </ins> span.ctxt.hash_stable(ctx, hasher); } }
Code change:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

Related discussion:
text: <ins> include ../../run-make-fulldeps/tools.mk # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) # Tests that we don't ICE during incremental compilation after modifying a # function span such that its previous end line exceeds the number of lines # in the new file, but its start line/column and length remain the same. SRC=$(TMPDIR)/src INCR=$(TMPDIR)/incr all: mkdir $(SRC) mkdir $(INCR) cp a.rs $(SRC)/main.rs $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs cp b.rs $(SRC)/main.rs $(RUSTC) -C incremental=$(INCR) $(SRC)/main.rs </ins>
Code change:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

Related discussion:
text: <ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1); } </ins>
Code change:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

Related discussion:
text: <ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1);//// } </ins>
Code change:
Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)

Related discussion:
text: include ../../run-make-fulldeps/tools.mk <ins> # FIXME https://github.com/rust-lang/rust/issues/78911 </ins> # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) all: foo