jiebi/CodeConvo huggingface dataset:
Code change:
.emit(); } EscapeError::MoreThanOneChar => { <ins> let msg = if mode.is_bytes() { "if you meant to write a byte string literal, use double quotes" } else { "if you meant to write a `str` literal, use double quotes" }; </ins> handler .struct_span_err( span_with_quotes,

Related discussion:
text: When creating a byte literal with single quotes, like , The error message says: But following the directions would not give us a literal, it would give a literal.
This should be easy to fix, by replacing the message with: when the literal is prefixed by . You may need to see work out which call is originating from (in ) to pass information about the nature of the literal.
Can I work on this?
go ahead! :) Let me know if you have any questions.
Hi, I have been doing some work in this issue, cause this is the first time I'm sending PR to rust, can you give me some feedback. Thanks!
Code change:
#[stable(feature = "ip_u32", since = "1.1.0")] impl From<Ipv4Addr> for u32 { <ins> /// It performs the conversion in network order (big-endian). </ins> fn from(ip: Ipv4Addr) -> u32 { let ip = ip.octets(); ((ip[0] as u32) << 24) + ((ip[1] as u32) << 16) + ((ip[2] as u32) << 8) + (ip[3] as u32)

Related discussion:
text: The conversion traits are implemented for conversion between and , but it is not clear what byte order is used.
It is network order, but that should be documented on the impl.
doc team triage: this would make a great first PR. I am happy to mentor anyone who wants to tackle this issue.
I'd like to, is someone else working on this?
nope, please do! Ping me if you need any help
Code change:
// it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

Related discussion:
text: liballoc's fails when run in Miri. The error occurs in the call: is called with a as argument. contains contains a shared reference to a slice; that slice is thus marked as "must not be mutated for the entire duration of this function call". calls calls calls calls , which eventually drops the . calls to re-arrange stuff (I have not fully understood this yet), and in some cases this will end up writing to memory that the slice in points to. I am not sure what the best way to fix this is. We have to fix holding (indirectly) a shared reference to something that it'll mutate during its . The mutation is likely there for a reason, so I guess the shared reference has to go. (FWIW, this shared reference already caused other trouble, but that was fixed by ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah I guess just change it to and toss in a PhantomData for the borrow. shrug
You mean, change this in as well? Sure, that should work. In principle this reduces the precision of compiler analyses on .
ahh misread. maybe would just not use Iter then. depends on what the impl looks like now
But the first thing it does is which should exhaust the such that its is an empty slice. I suppose its pointer will still be somewhere in the deque's memory, but with length 0 it can't actually read anything. Is that not good enough to appease Miri?
No. This code still matches the pattern There is no notion of "exhausting" or "consuming" a shared reference. When you create a shared reference with a certain lifetime, you promise that until that lifetime ends, no mutation happens. here is mutable so you can change what the slice points to, but that has no effect at all on the guarantees that have been made about the value that was initially passed to . Now, lifetimes are an entirely static concept, so for Stacked Borrows a "lifetime" generally is "until the pointer is used for the last time".
Code change:
// it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

Related discussion:
text: However, for the special case of a reference being passed to a function, Stacked Borrows asserts that the "lifetime" will last at least as long as the function the reference is pointed to. (This is enforced by the "barriers" explained .) This is extremely useful for optimizations.
forward to . I wouldn't want to copy those.
Oh, I also didn't realize that doesn't actually shrink down to an empty slice -- it only updates its indexes. It would otherwise have to use two slices for the wrapped head and tail. So that full shared reference does still exist after the iterator is exhausted. (This also raises the validity question of having references to uninitialized data.) Could we base on instead? We could arrange to work through that mutable reference too, so there's no question of mutable aliasing.
That might work. However, must not access in that case -- that would be in conflict with the unique reference in .
Hmm, does need to be covariant over ? I guess would break that.
Actually this idea of "consuming a shared ref" is far from unique to ... the following code also errors in Miri:
As I understand it, Miri and stacked borrows should be "more powerful" than the Rust borrow checker, right? So, is this an example where Miri does not match what Rust allows or is this a bug in Rust that could lead to undefined behaviour in safe code? ()
-- I believe is admitting that example as something that should be allowed. But this issue with involves raw pointers, which rustc doesn't check at all, so miri is in uncharted waters here.
This is up for us all to decide. I can't tell you. ;) Not necessary. I have argued that / are problematic long before Stacked Borrows. The lifetimes there are, strictly speaking, wrong. I think it would be reasonable to rule that they have to use raw pointers.
FWIW here is a stand-alone version of the testcase to reproduce this with Miri (but it needs access to some private internals):
See for the issue about whether Stacked Borrows should allow such code or not. For now, with , Miri accepts this code again. So I am going to close the issue here. It still represents an interesting data point to inform what Stacked Borrows rules should be.
Code change:
// it.  We do not write to `self` nor reborrow to a mutable reference. // Hence the raw pointer we created above, for `deque`, remains valid. let ring = self.buffer_as_slice(); <del> let iter = Iter::new(ring, drain_tail, drain_head); Drain::new(drain_head, head, iter, deque) </del> <ins> Drain::new(drain_head, head, ring, drain_tail, drain_head, deque) </ins> } }

Related discussion:
text: nods wisely just gotta stand still long enough for the spec to bend around you
;-) I don't think the decision is made either way, but for now with several counterexamples in libstd, it is not helpful for Miri to complain about this. Plus, this matches what we formalized in Coq; the basic optimizations that we considered so far are all fine with this change.
See there actually is a bug here right now, because we do emit for passed to a function. So what Miri found is actually UB in the LLVM IR that we are generating right now. Reopening for now, but maybe it makes more sense to treat this as a duplicate of
Smaller reproduction that I found in (a now closed dupe of this issue) that doesn't rely on VecDeque internals, that fails now with
re-enables the part of Stacked Borrows that got disabled (in parts) to work around the issue, before I knew that we actually have here and are risking real miscompilations.
claim
Code change:
.map(|v| v.parse().expect("failed to parse rust.llvm-libunwind")); if let Some(ref backends) = rust.codegen_backends { <del> config.rust_codegen_backends = backends.iter().map(|s| INTERNER.intern_str(s)).collect(); </del> <ins> let available_backends = vec!["llvm", "cranelift", "gcc"]; config.rust_codegen_backends = backends.iter().map(|s| { if let Some(backend) = s.strip_prefix(CODEGEN_BACKEND_PREFIX) { if available_backends.contains(&backend) { panic!("Invalid value '{s}' for 'rust.codegen-backends'. Instead, please use '{backend}'."); } else { println!("help: '{s}' for 'rust.codegen-backends' might fail.  Codegen backends are mostly defined without the '{CODEGEN_BACKEND_PREFIX}' prefix.  In this case, it would be referred to as '{backend}'."); } } INTERNER.intern_str(s) }).collect(); </ins> } config.rust_codegen_units = rust.codegen_units.map(threads_from_config);

Related discussion:
text: I tried this code: I expected to see this happen: An error saying that is invalid and should be instead. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --HEAD is branched from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
[[package]] name = "backtrace" <del> version = "0.3.25" </del> <ins> version = "0.3.29" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

Related discussion:
text: Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.
Code change:
[[package]] name = "backtrace" <del> version = "0.3.25" </del> <ins> version = "0.3.29" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "autocfg 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",

Related discussion:
text: That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs
Code change:
// Private support modules mod panicking; <del> #[unstable(feature = "ice_to_disk", issue = "none")] pub use panicking::panic_hook_with_disk_dump; </del> #[path = "../../backtrace/src/lib.rs"] #[allow(dead_code, unused_attributes, fuzzy_provenance_casts)] mod backtrace_rs;

Related discussion:
text: slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.
Code change:
b, index: 0, // unused len: 0,   // unused <ins> a_len: 0, // unused </ins> } }

Related discussion:
text: Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-
Code change:
let codegen_options = CodegenOptions::build(early_dcx, matches); let unstable_opts = UnstableOptions::build(early_dcx, matches); <del> let force_unstable_if_unmarked = unstable_opts.force_unstable_if_unmarked; </del> let dcx = new_dcx(error_format, None, diagnostic_width, &unstable_opts);

Related discussion:
text: for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you
Code change:
// This zip may have several times the same lifetime in `substs` paired with a different // lifetime from `id_substs`.  Simply `collect`ing the iterator is the correct behaviour: // it will pick the last one, which is the one we introduced in the impl-trait desugaring. <del> let map = substs.iter().zip(id_substs); let map: FxHashMap<GenericArg<'tcx>, GenericArg<'tcx>> = match origin { // HACK: The HIR lowering for async fn does not generate // any `+ Captures<'x>` bounds for the `impl Future<...>`, so all async fns with lifetimes // would now fail to compile. We should probably just make hir lowering fill this in properly. OpaqueTyOrigin::AsyncFn(_) => map.collect(), OpaqueTyOrigin::FnReturn(_) | OpaqueTyOrigin::TyAlias => { // Opaque types may only use regions that are bound. So for // ```rust // type Foo<'a, 'b, 'c> = impl Trait<'a> + 'b; // ``` // we may not use `'c` in the hidden type. let variances = tcx.variances_of(def_id); debug!(?variances); map.filter(|(_, v)| { let ty::GenericArgKind::Lifetime(lt) = v.unpack() else { return true }; let ty::ReEarlyBound(ebr) = lt.kind() else { bug!() }; variances[ebr.index as usize] == ty::Variance::Invariant }) .collect() } }; </del> <ins> let map = substs.iter().zip(id_substs).collect(); </ins> debug!("map = {:#?}", map); // Convert the type from the function into a type valid outside

Related discussion:
text: Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that
Code change:
} #[test] <ins> fn test_line_buffer_fail_flush() { // Issue #32085 struct FailFlushWriter<'a>(&'a mut Vec<u8>); impl<'a> Write for FailFlushWriter<'a> { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { self.0.extend_from_slice(buf); Ok(buf.len()) } fn flush(&mut self) -> io::Result<()> { Err(io::Error::new(io::ErrorKind::Other, "flush failed")) } } let mut buf = Vec::new(); { let mut writer = LineWriter::new(FailFlushWriter(&mut buf)); let to_write = b"abcndef"; if let Ok(written) = writer.write(to_write) { assert!(written < to_write.len(), "didn't flush on new line"); // PASS return; } } assert!(buf.is_empty(), "write returned an error but wrote data"); } #[test] </ins> fn test_line_buffer() { let mut writer = LineWriter::new(Vec::new()); writer.write(&[0]).unwrap();

Related discussion:
text: can return an error after a partial write if flushing the inner fails (). It should instead return , ignoring the error. I originally thought this problem was systematic so I audited stdlib. Apparently it isn't... See below. The write trait guarantees: However, this is violated all over stdlib. For example, if is written to a , the could write , try to flush, and then return an error due to a failed flush. However, has been written violating the spec. IMO, the solution is to return for partial writes and drop the error (if any). This should be safe because of write's write-xor-error guarantee. If the error was transient, the caller never needs to know. Otherwise, they will will learn of it on the next write. Here's everything in the stdlib that implements write (and should be audited): [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [x] in [ ] in (buggy) [x] in (buggy but unfixable and deprecated). [x] in [x] in [x] in [ ] in (panics on partial write) [x] in [x] in [x] in
Note: this could, e.g., theoretically cause to write on interrupt.
Ok. Actually, it turns out that only and are really problematic. on windows is bad but at least it's acknowledged in the code with a ...
So, is actually correct (I misread some of the code). This is just a bug in , nothing more.
Nice effort to audit it all!
Code change:
} #[test] <ins> #[allow(deprecated)] </ins> fn stream_smoke_test_ip4() { let server_ip = next_test_ip4(); let client_ip = next_test_ip4(); <ins> let dummy_ip = next_test_ip4(); </ins> let (tx1, rx1) = channel(); let (tx2, rx2) = channel(); spawn(proc() { <del> match UdpSocket::bind(client_ip) { Ok(client) => { let client = box client; let mut stream = client.connect(server_ip); rx1.recv(); stream.write([99]).unwrap(); </del> <ins> let send_as = |ip, val: &[u8]| { match UdpSocket::bind(ip) { Ok(client) => { let client = box client; let mut stream = client.connect(server_ip); stream.write(val).unwrap(); } Err(..) => fail!() </ins> } <del> Err(..) => fail!() } </del> <ins> }; rx1.recv(); send_as(dummy_ip, [98]); send_as(client_ip, [99]); </ins> tx2.send(()); });

Related discussion:
text: change this to something more appropriate. This was introduced in commit when still returned . This should either block until a message from the correct sender arrives or return an error.