jiebi/CodeConvo huggingface dataset:
Change:
} } <del> #[unstable(feature = "iter_copied", issue = "57127")] </del> <ins> #[stable(feature = "iter_copied", since = "1.36.0")] </ins> impl<'a, I, T: 'a> DoubleEndedIterator for Copied<I> where I: DoubleEndedIterator<Item=&'a T>, T: Copy {

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
Err(_) => false }, color: test::AutoColor, <ins> test_threads: None, </ins> } }

Discussion:
Discussion carried over from: rust-lang/cargo Test binaries created by rustc should have a option instead of (in addition to?) controlling the thread count with . It's not a consistent user experience to have some functionality controlled via environment variables and some via command line options. CLI options should be preferred since they encourage users to keep configuration local to a single execution of a test binary and not export it globally, making it affect other test runs perhaps accidentally. It would also make the output of more uniform and compact.
Agreed.
The ability to specify this in the somehow might be nice. One of my crates I'm working on needs all the tests run like this.
It is already set table by an env var, no? Cargo just can't specify them. So still not ideal but might work in the meantime. On Apr 16, 2016, 19:05 -0400, Nathan , wrote:
Oh cool thanks, I'll set that in my project.
Change:
<ins> // Copyright 2014 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. // Test that a partially specified trait object with unspecified associated // type does not ICE. #![feature(associated_types)] trait Foo { type A; } fn bar(x: &Foo) {} //~ERROR missing type for associated type `A` pub fn main() {} </ins>

Discussion:
cc The best thing to do here is to use (). Is the correct behaviour when using to treat as an unbounded type variable or to cause an error because is not well-specified?
My reading of the RFC is that it should be a compile error to use - all associated types in an object must be bound in the type (it is unclear from the RFC if having a default type for the associated type means we don't need an equality constraint for that type).
is very similar, but not quite a dup, the error message here is (which is wrong - it is not a self type issue).
Yes in general. I think it's fine to allow you to leave it off if there's a default.
I agree it should be a compile-time error to have an object type for which the values of some associated types are not specified (whether explicitly or via default). However, we have to be careful, because there can be a default that references (which is erased). We should catch this and report a nice error. See , which is related.
The ICE is fixed by
Change:
} (PlaceElem::Index(idx), Value::Aggregate { fields, .. }) => { let idx = prop.get_const(idx.into())?.immediate()?; <del> let idx = prop.ecx.read_target_usize(idx).ok()?; fields.get(FieldIdx::from_u32(idx.try_into().ok()?)).unwrap_or(&Value::Uninit) </del> <ins> let idx = prop.ecx.read_target_usize(idx).ok()?.try_into().ok()?; if idx <= FieldIdx::MAX_AS_U32 { fields.get(FieldIdx::from_u32(idx)).unwrap_or(&Value::Uninit) } else { return None; } </ins> } ( PlaceElem::ConstantIndex { offset, min_length: _, from_end: false },

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} // unsigned to signed (only positive bound) <ins> #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] </ins> macro_rules! try_from_upper_bounded { ($($target:ty),*) => {$( impl PrivateTryFromUsize for $target {

Discussion:
I have a Rust written using the msp430 backend. which means using the nightly compiler. Travis CI daily cron builds have been with the nightly compiler since March 27, 2018 with the following error (I am currently not in a position to get a backtrace/increase verbosity, I will update when possible): My msp430 firmware uses to create a for msp430 every time is updated, and recently a new feature has triggered a lint that causes compilation to fail due to an unused macro. Since can't be compiled, the whole build fails. A stopgap solution for now is to use a nightly before March 27, 2018 which compiles for msp430 successfully. cc: based on a in with PR might have tickled the lint into failing compilation for the msp430 backend?
This macro is conditionally used in code that depends on the target’s pointer width. I suspect that this error happens on any 16-bit platform. Adding to the macro’s definition should fix it. Would you send a PR and ping me for review? (As an aside, we should probably have CI on rust-lang/rust that libcore at least compiles for one 16-bit platform.)
Looking at 's fix I guess my q is: why don't 16 bit targets (msp430/avr) need this macro at all?
has some background on the removal of conversions for some combinations of integer types. Here we have a private trait with a generic impl based on and some concrete impls to "restore" missing conversions. The implementation of those concrete conversion depends on the size of : we either check that the source value isn’t too large for the target type, or check nothing at all because the target type covers all values of the source type. When is 16-bits, the minimum, only the latter kind of conversion is used.
Change:
} #[test] <ins> fn test_mem_mut_writer() { let mut vec = Vec::new(); let mut writer = Cursor::new(&mut vec); assert_eq!(writer.write(&[0]).unwrap(), 1); assert_eq!(writer.write(&[1, 2, 3]).unwrap(), 3); assert_eq!(writer.write(&[4, 5, 6, 7]).unwrap(), 4); let b: &[_] = &[0, 1, 2, 3, 4, 5, 6, 7]; assert_eq!(&writer.get_ref()[..], b); } #[test] </ins> fn test_box_slice_writer() { let mut writer = Cursor::new(vec![0u8; 9].into_boxed_slice()); assert_eq!(writer.position(), 0);

Discussion:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.
Change:
<ins> error[E0063]: missing field `private` in initializer of `Pub` --> $DIR/issue-79593.rs:10:9 | LL |         Pub {}; |         ^^^ missing `private` error[E0063]: missing field `y` in initializer of `Enum` --> $DIR/issue-79593.rs:12:9 | LL |         Enum::Variant { x: () }; |         ^^^^^^^^^^^^^ missing `y` error: cannot construct `Pub` with struct literal syntax due to inaccessible fields --> $DIR/issue-79593.rs:18:5 | LL |     foo::Pub {}; |     ^^^^^^^^ error[E0063]: missing field `y` in initializer of `Enum` --> $DIR/issue-79593.rs:23:5 | LL |     foo::Enum::Variant { x: () }; |     ^^^^^^^^^^^^^^^^^^ missing `y` error[E0063]: missing fields `x`, `y` in initializer of `Enum` --> $DIR/issue-79593.rs:25:5 | LL |     foo::Enum::Variant { }; |     ^^^^^^^^^^^^^^^^^^ missing `x`, `y` error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0063`. </ins>

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
backtrace = ["std/backtrace"] debug-jemalloc = ["std/debug-jemalloc"] jemalloc = ["std/jemalloc"] <ins> force_alloc_system = ["std/force_alloc_system"] </ins> panic-unwind = ["std/panic-unwind"]

Discussion:
Edit: see Seems to get past there fine if I remove .
Ok, works. That's the version rustbuild will download if left to its own devices. Bisecting built nightlies as my local rust gives this: nightly-2016-12-19 () - works [no nightlies] nightly-2016-12-29 - unrelated errors on some i128/u128 stuff before it gets to the relevant point [no nightlies] nightly-2017-01-04 () - broken
Note that this is really quick to reproduce (~1min), as it happens on the initial build of stage0 std. Here's the full log from : This issue may get a lot more attention once the stage0 downloaded compiler has its version bumped, as I suspect will be totally broken. Applying seems to fix it.
Ah I see, the more recent compiler is being detected as a local rebuild compiler, so rustbuild assumes it has a compiler with stage1 features and therefore performs a stage1 build, which seems to assume that jemalloc is available. On a positive note, this should never affect someone not using .
Ok I have a more solid understanding of the issue. Currently, a stage0-out libstd will never link against jemalloc. stage1-out is left to its own devices, linking against the default allocator for the compiler that's just been created (stage0-out) which is , system otherwise. However, a local rebuild uses for building the stage0 libstd, which means it uses the default allocator for the local rust. This tends to be we've disabled jemalloc, so it hasn't been built! Something along the lines of seems like the right approach, but I think some elaboration around the logic in this area is necessary in comments or something.
Change:
<ins> // Copyright 2014 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. struct S { //~ ERROR illegal recursive struct type; wrap the inner value in a box to make it representable element: Option<S> } fn main() { let x = S { element: None }; } </ins>

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
<del> // Copyright 2014 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. extern { const FOO: uint; //~ ERROR: unexpected token: `const` } fn main() {} </del>

Discussion:
These two tests seem both to test that is invalid. One of these (probably the one, because it’s newer) should be removed.
Change:
impl<'a> Iterator<(uint, uint)> for MatchIndices<'a> { #[inline] fn next(&mut self) -> Option<(uint, uint)> { <del> // See Issue #1932 for why this is a naive search let (h_len, n_len) = (self.haystack.len(), self.needle.len()); let mut match_start = 0; let mut match_i = 0; while self.position < h_len { if self.haystack[self.position] == self.needle[match_i] { if match_i == 0 { match_start = self.position; } match_i += 1; self.position += 1; if match_i == n_len { // found a match! return Some((match_start, self.position)); } } else { // failed match, backtrack if match_i > 0 { match_i = 0; self.position = match_start; } self.position += 1; } </del> <ins> match self.searcher { Naive(ref mut searcher) => searcher.next(self.haystack.as_bytes(), self.needle.as_bytes()), TwoWay(ref mut searcher) => searcher.next(self.haystack.as_bytes(), self.needle.as_bytes(), false), TwoWayLong(ref mut searcher) => searcher.next(self.haystack.as_bytes(), self.needle.as_bytes(), true) </ins> } <del> None </del> } }

Discussion:
The current implement of functions like are naive string searches, not using a more intelligent algorithm like Boyer-Moore (with a comment referring one to ). Unfortunately that means we're trounced when performing operations like that. e.g. glibc's : and A cursory search found which might be interesting to experiment with. came up on
This is for the case where the needle is a single character. In the case above the rust version is as fast or faster than the C version. Maybe there is a bug in the case for short needles.
Change:
<ins> // check-pass // Regression test for issue #79152 // // Tests that we can index an array in a const function const fn foo() { let mut array = [[0; 1]; 1]; array[0][0] = 1; } fn main() {} </ins>

Discussion:
Upstream ticket: I tried this code: I expected to see this happen: explanation The code compiles on but fails to build on rustc master which I assumes makes this a regression: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- version --<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
cargo-bisect-rustc says the regression is caused by
Maybe ?
cc
I assume this is the cause of the error:
MCVE:
Could be .
Reverting fixes the regression. The regression also appears in the for , but it appears either it was overlooked or the decision was made to merge anyway? cc
Assigning as and removing .
we probably have to update something here:
label E-needs-bisection E-needs-mcve
Change:
error: an inner attribute is not permitted following an outer doc comment <del> --> $DIR/inner-attr-after-doc-comment.rs:6:3 </del> <ins> --> $DIR/inner-attr-after-doc-comment.rs:6:1 </ins> | <del> LL | #![recursion_limit="100"] |   ^ </del> <ins> LL | / /** LL | |  * My module LL | |  */ | |___- previous doc comment LL | LL |   #![recursion_limit="100"] |   ^^^^^^^^^^^^^^^^^^^^^^^^^ not permitted following an outer attibute </ins> | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
<ins> //@ edition:2021 async fn clone_async_block(value: String) { for _ in 0..10 { async { //~ ERROR: use of moved value: `value` [E0382] drop(value); //~^ HELP: consider cloning the value if the performance cost is acceptable }.await } } fn main() {} </ins>

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #[allow(experimental)]; </ins> use std::unstable::simd::{i32x4, f32x4}; fn test_int(e: i32) -> i32 {

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this