jiebi/CodeConvo huggingface dataset:
Code change:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?

Related discussion:
text: <ins> error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/two-phase-multi-mut.rs:23:16 | LL |     foo.method(&mut foo); |     -----------^^^^^^^^- |     |          | |     |          second mutable borrow occurs here |     first mutable borrow occurs here |     borrow later used here error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/two-phase-multi-mut.rs:23:5 | LL |     foo.method(&mut foo); |     ^^^^^^^^^^^--------^ |     |          | |     |          first mutable borrow occurs here |     second mutable borrow occurs here |     borrow later used here error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0499`. </ins>
Code change:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // revisions: lxl nll //[lxl]compile-flags: -Z borrowck=mir -Z two-phase-borrows //[nll]compile-flags: -Z borrowck=mir -Z two-phase-borrows -Z nll // run-pass use std::io::Result; struct Foo {} pub trait FakeRead { fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize>; } impl FakeRead for Foo { fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { Ok(4) } } fn main() { let mut a = Foo {}; let mut v = Vec::new(); a.read_to_end(&mut v); } </ins>
Code change:
I've just got very surprised to find out that doesn't compile, but does. After some investigation, I found that is missing. Similar impl is present for though. I believe it'd be nice to implement it.
is to as is to , so check out , this implementation might meet your needs.
I've soled my problem immediately. I filed issue because I think we could help others by implementing the trait.

Related discussion:
text: } } <ins> #[stable(feature = "os_str_str_ref_eq", since = "1.28.0")] impl<'a> PartialEq<&'a str> for OsString { fn eq(&self, other: &&'a str) -> bool { **self == **other } } #[stable(feature = "os_str_str_ref_eq", since = "1.28.0")] impl<'a> PartialEq<OsString> for &'a str { fn eq(&self, other: &OsString) -> bool { **other == **self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl Eq for OsString {}
Code change:
I've just got very surprised to find out that doesn't compile, but does. After some investigation, I found that is missing. Similar impl is present for though. I believe it'd be nice to implement it.
is to as is to , so check out , this implementation might meet your needs.
I've soled my problem immediately. I filed issue because I think we could help others by implementing the trait.

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::ffi::OsString; fn main() { let os_str = OsString::from("Hello Rust!"); assert_eq!(os_str, "Hello Rust!"); assert_eq!("Hello Rust!", os_str); } </ins>
Code change:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)

Related discussion:
text: impl Sealed for ops::RangeInclusive<usize> {} #[stable(feature = "slice_get_slice", since = "1.28.0")] impl Sealed for ops::RangeToInclusive<usize> {} <ins> #[stable(feature = "slice_index_with_ops_bound_pair", since = "1.53.0")] impl Sealed for (ops::Bound<usize>, ops::Bound<usize>) {} </ins> } /// A helper trait used for indexing operations.
Code change:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)

Related discussion:
text: } )*) => {$( mod $case_name { <ins> #[allow(unused_imports)] use core::ops::Bound; </ins> #[test] fn pass() { let mut v = $data;
Code change:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)

Related discussion:
text: bad: data[7..=6]; message: "out of range"; } <ins> in mod boundpair_len { data: [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(6), Bound::Unbounded)] == []; good: data[(Bound::Unbounded, Bound::Included(5))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Unbounded, Bound::Excluded(6))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(0), Bound::Included(5))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(0), Bound::Excluded(6))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(2), Bound::Excluded(4))] == [2, 3]; good: data[(Bound::Excluded(1), Bound::Included(4))] == [2, 3, 4]; good: data[(Bound::Excluded(5), Bound::Excluded(6))] == []; good: data[(Bound::Included(6), Bound::Excluded(6))] == []; good: data[(Bound::Excluded(5), Bound::Included(5))] == []; good: data[(Bound::Included(6), Bound::Included(5))] == []; bad: data[(Bound::Unbounded, Bound::Included(6))]; message: "out of range"; } </ins> } panic_cases! {
Code change:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)

Related discussion:
text: bad: data[4..=2]; message: "but ends at"; } <ins> in mod boundpair_neg_width { data: [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(4), Bound::Excluded(4))] == []; bad: data[(Bound::Included(4), Bound::Excluded(3))]; message: "but ends at"; } </ins> } panic_cases! {
Code change:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)

Related discussion:
text: bad: data[..= usize::MAX]; message: "maximum usize"; } <ins> in mod boundpair_overflow_end { data: [0; 1]; bad: data[(Bound::Unbounded, Bound::Included(usize::MAX))]; message: "maximum usize"; } in mod boundpair_overflow_start { data: [0; 1]; bad: data[(Bound::Excluded(usize::MAX), Bound::Unbounded)]; message: "maximum usize"; } </ins> } // panic_cases! }
Code change:
Context: In order to experiment with an -aware , I was preparing to modify the lang item signature, and my first step was to ensure MIR passes the right type to begin with, as noted in Legitimately, I assumed that the MIR inline code was doing the right thing, so I mimicked it in . The resulting code actually works fine, as far as completing the 3 stages of rustc bootstrapping is involved. But before going the route for the -aware , I first tried removing the special handling of 's , trying to leave it to , shortcutting the lang item. This didn't go well, and produced a stage 1 compiler that would crash on a bad in libsyntax's . From which I derived a small test case that would exhibit the problem with my code. Anyways, I was going well over my head with this approach, thus switched to the signature change. So, what's the deal with this issue, will you ask? Well, it turns out that my MIR changes, essentially copied from MIR inlining, while they worked to produce an apparently working compiler, failed to compile that reduced testcase with an LLVM ERROR. I was wondering if I did something significantly different from what the MIT inlining pass was doing, so I tried to trigger it manually (since it's not enabled by default), and after some trial and error, got it to happen on a plain nightly compiler, with the following reduced testcase: Building with yields: (Note the is only there to force MIR inlining to happen without having to go over the required threshold ; liballoc's has ; similarly, the on avoids inlining of dealloc, to limit the effects on the MIR) Interestingly enough, and fail with the same error. The former outputs a truncated MIR (truncated at the entry of the first basic block), and the latter outputs nothing.
This is what from a run with looks like: Edit: and what the llvm-ir, as disassembled from output, looks like:
The problem is that the code path bb1-bb9-bb21-bb20 in IR, corresponding to bb0-bb1-bb6-bb5 in MIR, is impossible, yet exists. And in that code path, in MIR, in IR, is never initialized, and that's what LLVM doesn't like. I guess one way to look at is it to wonder why in MIR has a switch in the first place.
And the answer to that last question is false edges, according to the following MIR from the mir_map pass:
Actually, the path bb0-bb7-bb4-bb10-bb12 has without ever being initialized, but that's pre-elaborate-drops, and I hear drop is different then, so I don't know if it bad or not.
The weird switch that eventually causes the LLVM problem is by the elaborate-drops pass. The MIR after that phase looks like the following:
I think the most relevant fact is this difference between MIR inlining being enabled or not: with MIR inlining disabled, this basic block in MIR: becomes the following IR: with MIR inlining enabled, this basic block in MIR: becomes whiich is weird... where did the extra code go?
The changes from fix this issue.

Related discussion:
text: }, }; <del> let memory_locals = analyze::memory_locals(&fx); </del> <ins> let memory_locals = analyze::non_ssa_locals(&fx); </ins> // Allocate variable and temp allocas fx.locals = {
Code change:
When I run the test suite on campus, I get a failure in : The test says "this IP is unroutable, so connections should always time out," but evidently there's something about the setup at this location that was not anticipated. The results are the same whether I am connected to WiFi or through ethernet. Both connections go through the same router (a Linksys WRT120N I have physical access to, which doesn't appear to save any sort of logs), and I don't know where it goes after that. I can work around it by disconnecting from the internet entirely, and do not have issues when running the tests at home (same laptop, different network).
is your subnet 10.255.255.0/24 or 10.255.0.0/16 or 10.0.0.0/8 or anything similar? You can check by running . Either way, the test is ill formed and should be correctled.
I'm not there right now, but just in case I forget to come back to this, I do recall that the router is accessed through an IP in the 192.168.x.x subnet. (I'm not sure if this precludes the situation you have described) (I wish GitHub notifications had a "mark unread" feature!)
It appears not to be. wifi ethernet:
I think I must have misread something when making that test - the IP is inside of an address block reserved for private networks which means it could be routable depending on how your network is set up. We could instead use an IP from one of the documentation blocks like 192.0.2.0.
The address 10.255.255.1 is routable on my vanilla Ubuntu 18.04 box: The address 192.0.2.0 is not routable: Therefore, this test always fails on this box. I will file a PR changing it to 192.0.2.0.
This is a dup of .

Related discussion:
text: } #[test] <del> fn connect_timeout_unroutable() { // this IP is unroutable, so connections should always time out, // provided the network is reachable to begin with. let addr = "10.255.255.1:80".parse().unwrap(); let e = TcpStream::connect_timeout(&addr, Duration::from_millis(250)).unwrap_err(); assert!(e.kind() == io::ErrorKind::TimedOut || e.kind() == io::ErrorKind::Other, "bad error: {} {:?}", e, e.kind()); } #[test] </del> fn connect_timeout_unbound() { // bind and drop a socket to track down a "probably unassigned" port let socket = TcpListener::bind("127.0.0.1:0").unwrap();
Code change:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.

Related discussion:
text: touch "$TOOLSTATE_FILE" <ins> # Try to test all the tools and store the build/test success in the TOOLSTATE_FILE </ins> set +e python2.7 "$X_PY" test --no-fail-fast  src/doc/book
Code change:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.

Related discussion:
text: cat "$TOOLSTATE_FILE" echo <ins> # This function checks that if a tool's submodule changed, the tool's state must improve </ins> verify_status() { echo "Verifying status of $1..." if echo "$CHANGED_FILES" | grep -q "^M[[:blank:]]$2$"; then