jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Copyright 2017 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. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related discussion:
text: Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case
Code change:
<ins> // Copyright 2017 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. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related discussion:
text: Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()
Code change:
<ins> // Copyright 2017 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. // #39872, #39553 #![feature(conservative_impl_trait)] fn will_ice(something: &u32) -> impl Iterator<Item = &u32> { //~^ ERROR the trait bound `(): std::iter::Iterator` is not satisfied [E0277] } fn main() {} </ins>

Related discussion:
text: Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
Code change:
# (to avoid spending a lot of time cloning llvm) if [ "$EXTERNAL_LLVM" = "" ]; then RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --set build.optimized-compiler-builtins" <ins> # Likewise, only demand we test all LLVM components if we know we built LLVM with them export COMPILETEST_NEEDS_ALL_LLVM_COMPONENTS=1 </ins> elif [ "$DEPLOY$DEPLOY_ALT" = "1" ]; then echo "error: dist builds should always use optimized compiler-rt!" >&2 exit 1

Related discussion:
text: In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.
Code change:
[true] `{$param_name}` *[false] `fn` parameter } has {$lifetime_kind -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` } but calling `{assoc_item}` introduces an implicit `'static` lifetime requirement </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` } but calling `{$assoc_item}` introduces an implicit `'static` lifetime requirement </ins> .label1 = {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> } .label2 = ...is used and required to live as long as `'static` here because of an implicit lifetime bound on the {$has_impl_path -> <del> [named] `impl` of `{$impl_path}` *[anon] inherent `impl` </del> <ins> [true] `impl` of `{$impl_path}` *[false] inherent `impl` </ins> } infer_but_needs_to_satisfy = {$has_param_name -> [true] `{$param_name}` *[false] `fn` parameter } has {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> } but it needs to satisfy a `'static` lifetime requirement .influencer = this data with {$has_lifetime -> <del> [named] lifetime `{$lifetime}` *[anon] an anonymous lifetime `'_` </del> <ins> [true] lifetime `{$lifetime}` *[false] an anonymous lifetime `'_` </ins> }... .require = {$spans_empty -> *[true] ...is used and required to live as long as `'static` here

Related discussion:
text: [ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :
Code change:
} } <ins> const LOADERS: &Vec<&'static u8> = &Vec::new(); pub fn break_code() -> Option<&'static u8> { for loader in &*LOADERS { //~ ERROR cannot move out of a shared reference return Some(loader); } None } </ins> fn main() {}

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
} } <ins> const LOADERS: &Vec<&'static u8> = &Vec::new(); pub fn break_code() -> Option<&'static u8> { for loader in &*LOADERS { //~ ERROR cannot move out of a shared reference return Some(loader); } None } </ins> fn main() {}

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Compiles with replaced for <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
ArenaSet(vec![], &Z) } unsafe { <del> use std::sync::{Once, ONCE_INIT}; </del> <ins> use std::sync::Once; </ins> fn require_sync<T: Sync>(_: &T) { } unsafe fn __stability() -> &'static ArenaSet<Vec<u8>> { use std::mem::transmute; static mut DATA: *const ArenaSet<Vec<u8>> = 0 as *const ArenaSet<Vec<u8>>; <del> static mut ONCE: Once = ONCE_INIT; </del> <ins> static mut ONCE: Once = Once::new(); </ins> ONCE.call_once(|| { DATA = transmute ::<Box<ArenaSet<Vec<u8>>>, *const ArenaSet<Vec<u8>>>

Related discussion:
text: , anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new:
Code 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 we don't ICE due to encountering unsubstituted type // parameters when untupling FnOnce parameters during translation of // an unboxing shim. #![feature(unboxed_closures)] fn main() { let _: Box<FnOnce<(),()>> = box move |&mut:| {}; } </ins>

Related discussion:
text: Looks like substitutions weren't being applied in all places, resulting in it choking on an unsubstituted type parameter. The fix should hopefully be easy.
Code change:
<ins> error: `#[panic_handler]` function required, but not found error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:28:16 | LL |     take_range(0..1); |                ^^^^ |                | |                expected reference, found struct `core::ops::Range` |                help: consider borrowing here: `&(0..1)` | = note: expected type `&_` found type `core::ops::Range<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:33:16 | LL |     take_range(1..); |                ^^^ |                | |                expected reference, found struct `core::ops::RangeFrom` |                help: consider borrowing here: `&(1..)` | = note: expected type `&_` found type `core::ops::RangeFrom<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:38:16 | LL |     take_range(..); |                ^^ |                | |                expected reference, found struct `core::ops::RangeFull` |                help: consider borrowing here: `&(..)` | = note: expected type `&_` found type `core::ops::RangeFull` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:43:16 | LL |     take_range(0..=1); |                ^^^^^ |                | |                expected reference, found struct `core::ops::RangeInclusive` |                help: consider borrowing here: `&(0..=1)` | = note: expected type `&_` found type `core::ops::RangeInclusive<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:48:16 | LL |     take_range(..5); |                ^^^ |                | |                expected reference, found struct `core::ops::RangeTo` |                help: consider borrowing here: `&(..5)` | = note: expected type `&_` found type `core::ops::RangeTo<{integer}>` error[E0308]: mismatched types --> $DIR/issue-54505-no-std.rs:53:16 | LL |     take_range(..=42); |                ^^^^^ |                | |                expected reference, found struct `core::ops::RangeToInclusive` |                help: consider borrowing here: `&(..=42)` | = note: expected type `&_` found type `core::ops::RangeToInclusive<{integer}>` error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::BufWriter; /// use std::net::TcpStream; ///

Related discussion:
text: Update: this is the tracking issue for: is both unstable and deprecated, it should be removed. There is currently no way to tell whether there is any data buffered inside a BufReader. This is unfortunate because it means that an application has no way to know whether calls to read() and fillbuffer() will return instantly or trigger a potentially expensive call to the underlying Reader. I propose adding an is_empty() method to BufReader to fill this gap.
now that has been merged, I'm guessing this should get the label?
What's left for this to stabilize? I'm parsing bytes from a to MsgPack using . The function will stop parsing once a valid MsgPack value has been found. But in my application the parsing should fail if the buffer hasn't been consumed completely. Checking would probably be the cleanest way to do so.
the method proposed in may also be useful for that purpose, though that may take even longer to land.
This is the tracking issue for: Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
This seems fine to stabilize, but it seems like it'd be more useful to know how many bytes are buffered, rather than just that there are some number of bytes.
Why not both? Slices have even though it’s somewhat redundant with .
For sure. Would it be reasonable to try to squeeze that into this stabilization?
Sounds ok to me, though we should probably (re)start FCP after the implementation is merged.
Naming wise, I don't think fits since that seems to me like it'd refer to the length of the entire reader rather than just the current buffered data (similarly is a bit confusing). How about and ?
Agreed. Sounds good to me.
Alternatively, we could add to just return the buffer, which is also a thing people want separately from this issue. At that point seems not much worse than so we could have one method instead of three.
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::BufWriter; /// use std::net::TcpStream; ///

Related discussion:
text: adds and deprecates .
:bell: This is now entering its final comment period, as per the . :bell:
With alternative (and IMO better) proposal just introduced, should this still be going into its final comment period?
fcp cancel Let’s start again after has landed.
proposal cancelled.
We should likely also add a method to for consistency?
That can't be done backwards compatibly.
why not? It's just a , right? Just like .
Oh derp I somehow read that as .
Haha, no worries. Is there even a trait?
No there isn't _Off of the topic of me needing more caffeine, it definitely seems reasonable to add to , and fold it into the same feature gate as 's.
It has been a while since landed. Is this ready to stabilize?
is implemented, but discussed above is not. (I’ve updated the issue’s description with the current status.)
Wait, we aren't proposing to stabilize the (already deprecated) is_empty method are we?
No, sorry I didn’t clarify. An API marked both unstable and deprecated is to be removed (after something like a couple release cycles of deprecation period, which we’re at in this case).
I'm excited to see that this is so close to landing. Is this still waiting on an implementation of ? Would it be possible to track that feature separately to unblock this one?
Bump. Is there anything else blocking stabilization?
Is there any particular reason not to add to ? It seems like a useful enough general-purpose API ("get me however many bytes you can easily give me"), and I found myself looking for such a method while working on parser tooling. Individual implementations could make stricter guarantees about the lower bounds, of which "at least the unconsumed fraction of the last " would be a common one.
Yeah, this has been a while. is this ready for a vote to stabilize?
This issue seems to have been stuck in a strange limbo state for quite a while now. Pinging more people the rfcbot mentioned...
Sorry we dropped the ball here. This is now one method on the and structs. 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.
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::BufWriter; /// use std::net::TcpStream; ///

Related discussion:
text: 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.
There is nothing called in std. Did you mean the trait? A downside is that to add it now we would have to make it a default method, which would (at first) have an inconsistent behavior with for existing impls. We can update impls in std at the same time, but that leaves impls in other crates.
:bell: This is now entering its final comment period, as per the . :bell:
Sorry, yes, I meant . For my use cases, not having a lower bound is fine. Anything that does can use a marker subtrait that encompasses that guarantee. I think the only stipulation should be that it not provide more than , but less is fine. For example, an implementation might copy existing data around on to make a larger contiguous segment, but can't/shouldn't do so in (I think it should be a cheap conversion, wouldn't have been an unreasonable name).
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.
Code change:
exact_paths: DefIdMap<Vec<Symbol>>, modules: Vec<Module<'tcx>>, is_importable_from_parent: bool, <ins> inside_body: bool, </ins> } impl<'a, 'tcx> RustdocVisitor<'a, 'tcx> {

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.