jiebi/CodeConvo huggingface dataset:
Change:
/// assert_eq!(read_future.await, "Hello, World!".to_owned()); /// # } /// ``` <del> #[unstable(feature = "future_poll_fn", issue = "72302")] </del> <ins> #[stable(feature = "future_poll_fn", since = "1.64.0")] </ins> pub fn poll_fn<T, F>(f: F) -> PollFn<F> where F: FnMut(&mut Context<'_>) -> Poll<T>,

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? 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] [ ] [ ] 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. This will be merged soon.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
pub fn impls_are_allowed_to_overlap(self, def_id1: DefId, def_id2: DefId) -> Option<ImplOverlapKind> { <ins> // If either trait impl references an error, they're allowed to overlap, // as one of them essentially doesn't exist. if self.impl_trait_ref(def_id1).map_or(false, |tr| tr.references_error()) || self.impl_trait_ref(def_id2).map_or(false, |tr| tr.references_error()) { return Some(ImplOverlapKind::Permitted); } </ins> let is_legit = if self.features().overlapping_marker_traits { let trait1_is_empty = self.impl_trait_ref(def_id1) .map_or(false, |trait_ref| {

Discussion:
(edit: see below) The first error is sensical: But the knock-on errors are not:
Minimized:
Change:
<del> Subproject commit 0af6c732ec6ca189cd7725e4a7d4290793046e83 </del> <ins> Subproject commit af8f9eb61a2ad4ee1f2d3f46d157b93a47c6a4bf </ins>

Discussion:
I tried this code: I expected to see this happen: these two pieces of code produced the same assembly Instead, this happened: the first version generates worse code It most recently worked on: 1.76 :
The main branch of LLVM may have fixed this issue:
Whoops, compared against 1.76, my mistake.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I have bisected to (). But I'm not sure if this match the backport rules. I have submitted , but it may be rejected.
label llvm-fixed-upstream
Change:
<ins> // check-pass #![allow(incomplete_features)] #![feature(adt_const_params, return_position_impl_trait_in_trait)] pub struct Element; pub trait Node { fn elements<const T: &'static str>(&self) -> impl Iterator<Item = Element>; } fn main() {} </ins>

Discussion:
<!-- 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. --<!-- 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 --
claim
Regression in
Change:
#[derive(Debug)] pub struct DirBuilder { mode: mode_t } <ins> cfg_has_statx! {{ impl FileAttr { fn from_stat64(stat: stat64) -> Self { Self { stat, statx_extra_fields: None } } } } else { impl FileAttr { fn from_stat64(stat: stat64) -> Self { Self { stat } } } }} </ins> impl FileAttr { pub fn size(&self) -> u64 { self.stat.st_size as u64 } pub fn perm(&self) -> FilePermissions {

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
// Nanosecond calculations can't overflow because both values are below 1e9. let nsec = dur.subsec_nanos() as libc::c_long + now.tv_nsec as libc::c_long; <del> // FIXME: Casting u64 into time_t could truncate the value. let sec = (dur.as_secs() as libc::time_t) </del> <ins> let sec = saturating_cast_to_time_t(dur.as_secs()) </ins> .checked_add((nsec / 1_000_000_000) as libc::time_t) .and_then(|s| s.checked_add(now.tv_sec)); let nsec = nsec % 1_000_000_000;

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
<ins> error[E0433]: failed to resolve: `Self` is only available in impls, traits, and type definitions --> $DIR/ice-array-into-iter-lint-issue-121532.rs:7:12 | LL | fn func(a: Self::ItemsIterator) { |            ^^^^ `Self` is only available in impls, traits, and type definitions error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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: [lintmod] linting top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
claim
The ICE occurs due to the on this line: The underlying reason is that typeck result is tainted due to the bad arg type in the user's code and therefore returns .
Change:
<ins> // edition:2018 #![no_core] #![feature(no_core)] // @matches 'issue_89852/sidebar-items.js' '"repro"' // @!matches 'issue_89852/sidebar-items.js' '"repro".*"repro"' #[macro_export] macro_rules! repro { () => {}; } pub use crate::repro as repro2; </ins>

Discussion:
<brIn current stable, and nightly-2021-08-28: ! <brIn current beta, current nightly, and nightly-2021-08-29: ! <brNotice that appears twice in the sidebar under the list of macros exported by the crate. Bisects to .
searched nightlies: from nightly-2021-08-10 to nightly-2021-09-26 regressed nightly: nightly-2021-08-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It looks like in both versions there's also a bug where is not shown.
I think the fix here is to show "pub use repro as repro2" in the crate root - it sounds like currently it's being unconditionally inlined and then on top of that using the original name instead of the new one.
This also affect the unstable json output of rustdoc. If we take the example given by there are 3 items (1 reexport + 2 macro) instead of only two: The bug seems that the macro appears for whatever reason 2 times instead of only one.
Change:
<ins> // build-pass #![feature(allocator_api)] use std::alloc::Allocator; struct BigAllocator([usize; 2]); unsafe impl Allocator for BigAllocator { fn allocate( &self, _: std::alloc::Layout, ) -> Result<std::ptr::NonNull<[u8]>, std::alloc::AllocError> { todo!() } unsafe fn deallocate(&self, _: std::ptr::NonNull<u8>, _: std::alloc::Layout) { todo!() } } fn main() { Box::new_in((), &std::alloc::Global); Box::new_in((), BigAllocator([0; 2])); } </ins>

Discussion:
Hello, I've tested the feature and encountered an ICE: If tried this code (): I've used the "current" playground nighty compiler, but I can reproduce locally. : and also on <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label: +requires-nightly +A-allocators
Slightly minimized: Doesn't ICE anymore if you either remove the field or if it is not an array.
Duplicate of ?
No, not really a duplicate (but possibly related). This issue and the linked one have completely different backtraces.
Just by the way, using inline storage in an allocator is actually unsafe unless the impl of the trait is using a reference. See the Allocator safety notes: (Emphasis mine) ()
FWIW this is also triggered with uninhabited types. Though looks like only when drop glue is involved. Eg works but doesn't.
Another MCVE that leads to this ICE: found in
claim
Change:
} } <ins> #[derive(Default)] struct Buffer { messages: Vec<String>, has_errors: bool, } </ins> struct BufferEmitter { <del> messages: Lrc<Lock<Vec<String>>>, </del> <ins> buffer: Lrc<Lock<Buffer>>, </ins> } impl Emitter for BufferEmitter { fn emit_diagnostic(&mut self, diag: &Diagnostic) { <del> self.messages.borrow_mut().push(format!("error from rustc: {}", diag.message[0].0)); </del> <ins> let mut buffer = self.buffer.borrow_mut(); buffer.messages.push(format!("error from rustc: {}", diag.message[0].0)); if diag.is_error() { buffer.has_errors = true; } </ins> } fn source_map(&self) -> Option<&Lrc<SourceMap>> { None } } <del> enum CodeBlockInvalid { SyntaxError, Empty, } </del>

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
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. #![feature(overloaded_calls)] use std::{fmt, ops}; struct Shower<T> { x: T } impl<T: fmt::Show> ops::Fn<(), ()> for Shower<T> { fn call(&self, _args: ()) { //~^ ERROR `call` has an incompatible type for trait: expected "rust-call" fn but found "Rust" fn println!("{}", self.x); } } fn make_shower<T>(x: T) -> Shower<T> { Shower { x: x } } pub fn main() { let show3 = make_shower(3i); show3(); } </ins>

Discussion:
Code sample: Backtrace and debug log:
Similar code without the feature does not cause a compiler error:
A smaller test case:
Neither of the test cases are ICEing for me today, I'm seeing the following:
Flagging as needstest

The error message doesn't say that the problem is mismatching mutability.
Looks like this can be closed, this is now: Edit: though now the complaint might be that it doesn't single out 'other'
Flagging as needstest (just in case a test doesn't already exist)
Change:
#[inline] fn visit_ty(&mut self, ty: &mut Ty<'tcx>, _: TyContext) { <del> *ty = self.tcx.normalize_erasing_regions(self.param_env, ty); </del> <ins> // We have to use `try_normalize_erasing_regions` here, since it's // possible that we visit impossible-to-satisfy where clauses here, // see #91745 *ty = self.tcx.try_normalize_erasing_regions(self.param_env, *ty).unwrap_or(ty); </ins> } }

Discussion:
<!-- 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. --code from cc <!-- 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. --: Note that is required to reproduce the ICE <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc maybe you have an idea why this still crashes with ?
No, I don't unfortunately. The version of version I worked on is meant to be called before typecheck has finished and where normalization could still fail. This call seems to occur during codegen, where normalization should (in theory) always succeed (or rather errors should have been caught earlier), but I'm not that familiar with the later stages of the compiler, so I might be missing something.
This normalization is happening in an optimization pass () which can run on MIR that can never be codegenned. In this case, the method impl has an impossible-to-satisfy clause, so it can never actually be called or codegenned. The optimization pass should be changed to use - it can just do nothing if it fails.
Thanks for pointing out the problem. Would you like to open a PR for this or are you ok with me trying to fix this?
Feel free to open a PR
Change:
if let Some(expr) = expr { unpack!(block = this.into(destination, block, expr)); } else { <del> this.cfg.push_assign_unit(block, source_info, destination); </del> <ins> // If a block has no trailing expression, then it is given an implicit return type. // This return type is usually `()`, unless the block is diverging, in which case the // return type is `!`. For the unit type, we need to actually return the unit, but in // the case of `!`, no return value is required, as the block will never return. let tcx = this.hir.tcx(); let ty = destination.ty(&this.local_decls, tcx).to_ty(tcx); if ty.is_nil() { // We only want to assign an implicit `()` as the return value of the block if the // block does not diverge. (Otherwise, we may try to assign a unit to a `!`-type.) this.cfg.push_assign_unit(block, source_info, destination); } </ins> } // Finally, we pop all the let scopes before exiting out from the scope of block // itself.

Discussion:
The following error results from dereferencing a as in this code:
What’s the correct fix? Compiler error with a nice error message?
I think this should compile and UB, but a lint against this is probably a good idea.
Reduced test case:
I'm working on a fix for this. Progress on . The idea is to avoid the typing issues entirely by terminating the blocks with as soon as a -value is constructed. Currently the examples given here are fixed, but some more convoluted examples still crash.
Change:
libssl-dev  pkg-config <del> COPY dist-x86_64-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh x86_64 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh x86_64 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-ar  <del> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-gcc  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-g++ </del> <ins> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang++ </ins> ENV HOSTS=x86_64-unknown-freebsd

Discussion:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…
Change:
<ins> error[E0057]: this function takes 0 arguments but 1 argument was supplied --> $DIR/wrong_argument_ice-4.rs:2:5 | LL |       (|| {})(|| { |  _____^^^^^^^_- | |     | | |     expected 0 arguments LL | | LL | |         let b = 1; LL | |     }); | |_____- supplied 1 argument error: aborting due to previous error For more information about this error, try `rustc --explain E0057`. </ins>

Discussion:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized:
Change:
impl Tarballer { /// Generates the actual tarballs pub fn run(self) -> Result<()> { <ins> if let CompressionProfile::NoOp = self.compression_profile { return Ok(()); } </ins> let tarball_name = self.output.clone() + ".tar"; let encoder = CombinedEncoder::new( self.compression_formats

Discussion:
Right now when doing a local , we first compress the artifacts with max compression ratio, just to immediately unpack them again when installing them to disk. Making the compression level less aggressive or skipping it altogether can probably save 5-10 minutes on an x.py install. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc You probably want to use the gzip'd artifacts which are less intensely compressed.
tbh it seems strange that we're compressing these at all - why not put them into an uncompressed .tar archive when using ?
or even better, copy them directly from the build directory to the install directory without going through a .tar archive first.
claim
Skipping the compressions and archiving in favor of directly copying the artifacts seems like a reasonable solution for . But it requires significant changes to how we currently handle . I'm planning to do a comprehensive review on bootstrapping from all angles(including T-bootstrap issues) and make a roadmap for future development. To avoid conflicts(e.g, if we have improvement ideas on dist/install modules, implementing this might increase the technical debt which will require more effort from the team), I will postpone this task for now and re-prioritize it once we have organized the plans.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-35030.rs:19:14 | 19 |         Some(true) |              ^^^^ expected type parameter, found bool | = note: expected type `bool` (type parameter) = note:    found type `bool` (bool) error: aborting due to previous error </ins>

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like: