jiebi/CodeConvo huggingface dataset:
Change:
Currently is parsed as . I think it should be parsed as , to be consistent with handling of other similar "open" binary and prefix expressions (lambdas can be viewed as a form of a prefix expression). Consider these expressions: They are parsed as The last two cases seem to be different from others and wrong. on IRC suggested that this behavior could have been introduced accidentally during transition from lambdas with blocks as bodies to lambdas with arbitrary expressions as bodies. If this is a bug, fixing it can render some previously valid programs invalid, but this seems rater unlikely, as bare lambdas rarely end up in conditionals. It is possible though:
cc
Oh and I didn't mean I had introduced the distinction accidentally but rather that before I made that simplification, the code was block-oriented so the need for it to obey typical expression rules may have been overlooked and I didn't think about it (to consider fixing it).

Discussion:
let decl = self.parse_fn_block_decl()?; let decl_hi = self.prev_span; let body = match decl.output { <del> FunctionRetTy::Default(_) => self.parse_expr()?, </del> <ins> FunctionRetTy::Default(_) => { let restrictions = self.restrictions - RESTRICTION_STMT_EXPR; self.parse_expr_res(restrictions, None)? }, </ins> _ => { // If an explicit return type is given, require a // block to appear (RFC 968).

<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. // compile-flags: -Z parse-only struct Foo { x: isize, } impl Foo { fn hi(&self) -> bool { true } } fn main() { while || Foo { x: 3    //~ ERROR expected type, found `3` }.hi() { //~ ERROR expected one of `.`, `;`, `?`, `}`, or an operator, found `{` println!("yo"); } } </ins>

<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. pub fn main() { // Test that lambdas behave as unary expressions with block-like expressions -if true { 1 } else { 2 } * 3; || if true { 1 } else { 2 } * 3; // The following is invalid and parses as `if true { 1 } else { 2 }; *3` // if true { 1 } else { 2 } * 3 } </ins>
Change:
According to the return type should be but rustc expects a Test case: Compiler error:
cc
I think the has an incorrect return type?

Discussion:
"intrinsic": "256_sad_epu8", "width": [256], "llvm": "psad.bw", <del> "ret": "u8", </del> <ins> "ret": "u64", </ins> "args": ["0", "0"] }, {

}, "_mm256_sad_epu8" => Intrinsic { inputs: { static INPUTS: [&'static Type; 2] = [&::U8x32, &::U8x32]; &INPUTS }, <del> output: &::U8x32, </del> <ins> output: &::U64x4, </ins> definition: Named("llvm.x86.avx2.psad.bw") }, "_mm256_shuffle_epi8" => Intrinsic {
Change:
Currently, the following program because isn't . Is this the desired behavior, or should we consider making it or ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also won't compile because ?
Ah, right you are. :
does not require anymore (tested with rustc 1.55.0). The original issue is still valid. Since poisons itself on panic, it should be considered unwind safe.
We discussed this very briefly in the libs api meeting. It seems fine to add this impl.
claim Going to take a stab at this one.

Discussion:
use crate::cell::Cell; use crate::fmt; use crate::marker; <ins> use crate::panic::{RefUnwindSafe, UnwindSafe}; </ins> use crate::sync::atomic::{AtomicBool, AtomicUsize, Ordering}; use crate::thread::{self, Thread};

#[stable(feature = "rust1", since = "1.0.0")] unsafe impl Send for Once {} <ins> #[stable(feature = "sync_once_unwind_safe", since = "1.59.0")] impl UnwindSafe for Once {} #[stable(feature = "sync_once_unwind_safe", since = "1.59.0")] impl RefUnwindSafe for Once {} </ins> /// State yielded to [`Once::call_once_force()`]’s closure parameter. The state /// can be used to query the poison status of the [`Once`]. #[stable(feature = "once_poison", since = "1.51.0")]
Change:
Trait bounds on associated types seem to be required, not implied, when the trait in question mentions an associated type on a type parameter. Concretely, this code (or ) produces an error: despite the bound being required by the definition of itself, and in fact this means that the trait can never be mentioned. This similar example () that doesn't use an associated type in the trait parameter compiles: while this version (), which uses a third trait to avoid the self-reference, does not: Is this just a missing normalization step?
Pretty sure I encountered the same bug when specifying an associated type explicitly in a signature.
/cc you wanted to ensure this test case fell into the trait system rewrite.
I've just run into this as well, it seems. Here's a very simple example:

Discussion:
<ins> // check-pass use std::borrow::Borrow; trait TNode: Sized { type ConcreteElement: TElement<ConcreteNode = Self>; } trait TElement: Sized { type ConcreteNode: TNode<ConcreteElement = Self>; } trait DomTraversal<N: TNode> { type BorrowElement: Borrow<N::ConcreteElement>; } #[allow(dead_code)] fn recalc_style_at<E, D>() where E: TElement, D: DomTraversal<E::ConcreteNode>, { } fn main() {} </ins>

<ins> // check-pass pub trait Test { type Item; type Bundle: From<Self::Item>; } fn fails<T>() where T: Test<Item = String>, { } fn main() {} </ins>

<ins> // check-pass trait Foo { type FooT: Foo; } impl Foo for () { type FooT = (); } trait Bar<T: Foo> { type BarT: Bar<T::FooT>; } impl Bar<()> for () { type BarT = (); } #[allow(dead_code)] fn test<C: Bar<()>>() { } fn main() { } </ins>

<ins> // check-pass #![feature(associated_type_bounds)] #![feature(type_alias_impl_trait)] fn main() {} trait Bar { type Assoc; } trait Thing { type Out; fn func() -> Self::Out; } struct AssocIsCopy; impl Bar for AssocIsCopy { type Assoc = u8; } impl Thing for AssocIsCopy { type Out = impl Bar<Assoc: Copy>; fn func() -> Self::Out { AssocIsCopy } } </ins>
Change:
Considering following snippets: Currently on linux, the spawned thread will just panic at option unwrap which happen inside std library: It makes no sense to call join inside the associated thread, but a meaningless panic is sure not the good way to handle this situation. Maybe we should return an error which contains the join handle, so the caller can recover the failure. If panic is preferred, then a more friendly message should be good for users.
This seems like a reasonable-ish panic, though it would perhaps be better to have the error be returned within the result, though the current behavior is as documented, so I think it's reasonable.

Discussion:
unsafe { let ret = libc::pthread_join(self.id, ptr::null_mut()); mem::forget(self); <del> debug_assert_eq!(ret, 0); </del> <ins> assert!(ret == 0, "failed to join thread: {}", io::Error::from_raw_os_error(ret)); </ins> } }

pub const WAIT_OBJECT_0: DWORD = 0x00000000; pub const WAIT_TIMEOUT: DWORD = 258; <ins> pub const WAIT_FAILED: DWORD = 0xFFFFFFFF; </ins> #[cfg(target_env = "msvc")] pub const MAX_SYM_NAME: usize = 2000;

} pub fn join(self) { <del> unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE); } </del> <ins> let rc = unsafe { c::WaitForSingleObject(self.handle.raw(), c::INFINITE) }; if rc == c::WAIT_FAILED { panic!("failed to join on thread: {}", io::Error::last_os_error()); } </ins> } pub fn yield_now() {

/// [`Err`]: ../../std/result/enum.Result.html#variant.Err /// [`panic`]: ../../std/macro.panic.html /// <ins> /// # Panics /// /// This function may panic on some platforms if a thread attempts to join /// itself or otherwise may create a deadlock with joining threads. /// </ins> /// # Examples /// /// ```
Change:
In attempting to find some local hot spots in rustc I've been playing around with various benchmarks. If you use this script to generate a Rust and a C file (which should be equivalent) I've benchmarked with: The is particularly illuminating, the highest portions being: ! It looks like the main slowdown of the the translation item collection is related to the pass?
I fixed an "obvious omission" in but I'm not sure why we're creating such massive bit sets in the first place
This also peaks at using 32GB (!) of memory, a , the peak of which
cc because of ElaborateDrops. Oh interesting, optimizing MIR now shows up as part of item collection because of on-demand.
Nightly rustc takes 16 seconds, vs. 12 seconds with clang-14. Looking over a profile I don't see any clear hot spots where we're doing obviously wasted/unnecessary work, so I think we can probably close this as no longer an interesting case study.

Discussion:
pub struct Union; impl BitwiseOperator for Union { <ins> #[inline] </ins> fn join(&self, a: usize, b: usize) -> usize { a | b } } pub struct Subtract; impl BitwiseOperator for Subtract { <ins> #[inline] </ins> fn join(&self, a: usize, b: usize) -> usize { a & !b } }
Change:
I was attempting to use to figure out how my program was invoked so I could respond with convenience code paths (analogous to how is basically a shortcut/alias for ) when I noticed inconsistent behavior between OS X and Linux when the program was invoked via a symbolic link. For convenience I have bundled these in a repo: rustc 1.19.0 ( 2017-07-17) On all platforms, I would expect to get: On Mac OS X, I get: On Linux, I get: The for implies that if you run from the symlink, you'll get the name of the symlink, not the dereferenced target of the symlink; however, the documentation's example does not actually include a symbolic link (), but rather a hard link ().
I suspect this will have to be fixed in documentation (probably by just being more vague about what different platforms return) since I'm not sure there's a way to get what you want in Linux: I note that the busybox docker container uses hardlinks in , presumably due to the same problem (it's a multi-call binary, as you want to provide). Putting aside , you can possibly solve your use-case with the first element of instead.
Behavior on Windows is similar to the behavior on OS X. It calls which gets the path from the file handle for the module handle, which returns a canonical path to the file.
opened a pr for this:

Discussion:
/// Returns the full filesystem path of the current running executable. /// <del> /// The path returned is not necessarily a "real path" of the executable as /// there may be intermediate symlinks. </del> <ins> /// # Platform-specific behavior /// /// If the executable was invoked through a symbolic link, some platforms will /// return the path of the symbolic link and other platforms will return the /// path of the symbolic link’s target. </ins> /// /// # Errors ///

/// Ok("/home/alex/foo") /// ``` /// <del> /// And you make a symbolic link of the program: </del> <ins> /// And you make a hard link of the program: </ins> /// /// ```bash /// $ ln foo bar /// ``` /// <del> /// When you run it, you won't get the original executable, you'll get the /// symlink: </del> <ins> /// When you run it, you won’t get the path of the original executable, you’ll /// get the path of the hard link: </ins> /// /// ```bash /// $ ./bar

/// ``` /// /// This sort of behavior has been known to [lead to privilege escalation] when <del> /// used incorrectly, for example. </del> <ins> /// used incorrectly. </ins> /// <del> /// [lead to privilege escalation]: http://securityvulns.com/Wdocument183.html </del> <ins> /// [lead to privilege escalation]: https://securityvulns.com/Wdocument183.html </ins> /// /// # Examples ///

/// /// match env::current_exe() { ///     Ok(exe_path) => println!("Path of this executable is: {}", <del> ///                               exe_path.display()), </del> <ins> ///                              exe_path.display()), </ins> ///     Err(e) => println!("failed to get current exe path: {}", e), /// }; /// ```
Change:
When working locally dmajor has found that apparently disabling LLVM assertions doesn't work on MSVC when compiling LLVM. Despite apparently they're still compiled in! This isn't the first time IIRC of LLVM definitions and such not actually getting communicated to the msbuild build system. My guess is that this is a bug in LLVM's build system or something like that. In any case I think we should at least start using by default if we detect ninja in PATH, and otherwise we may want to print warnings on "known bad" cases saying that msbuild isn't reading configuration options correctly, recommending a download of ninja
It looks like may also be communicated to msbuild but not implemented? It apparently works well though when compiled with ninja!

Discussion:
} // Ninja is currently only used for LLVM itself. <del> // Some Linux distros rename `ninja` to `ninja-build`. // CMake can work with either binary name. if building_llvm && build.config.ninja && cmd_finder.maybe_have("ninja-build").is_none() { cmd_finder.must_have("ninja"); </del> <ins> if building_llvm { if build.config.ninja { // Some Linux distros rename `ninja` to `ninja-build`. // CMake can work with either binary name. if cmd_finder.maybe_have("ninja-build").is_none() { cmd_finder.must_have("ninja"); } } // If ninja isn't enabled but we're building for MSVC then we try // doubly hard to enable it. It was realized in #43767 that the msbuild // CMake generator for MSVC doesn't respect configuration options like // disabling LLVM assertions, which can often be quite important! // // In these cases we automatically enable Ninja if we find it in the // environment. if !build.config.ninja && build.config.build.contains("msvc") { if cmd_finder.maybe_have("ninja").is_some() { build.config.ninja = true; } } </ins> } build.config.python = build.config.python.take().map(|p| cmd_finder.must_have(p))
Change:
The text for references a non-existent Rust version. "Here's an example that is currently an error, but may work in a future version of Rust:" This isn't really helpful for understanding the error, and isn't that helpful of a predictor of Rust's future. Reported by
The text after the example is instructive. In theory, if you read the RFC, then you'd expect that code to work.
- we shouldn't reference non-existent versions of Rust in our error codes. It's confusing (as pointed to by the link I shared). It's fine to talk about them in other RFCs, but not anything a new user might encounter.
Opened a PR for this:

Discussion:
fn baz<'a>(x: &'a str, y: &str) -> &str { } ``` <del> Here's an example that is currently an error, but may work in a future version of Rust: ```compile_fail,E0106 struct Foo<'a>(&'a str); trait Quux { } impl Quux for Foo { } ``` </del> Lifetime elision in implementation headers was part of the lifetime elision RFC. It is, however, [currently unimplemented][iss15872].
Change:
The time to complete the build has became dangerously close to 3 hours starting from August 13th. ! Assuming AppVeyor is normal, I suspect one or more of the following are responsible: ( "Expose all OS-specific modules in libstd doc.") (1 hr 50 min → 2 hr 3 min = +13 min) ( "Rustbuild cleanups/fixes and improvements") (2 hr 3 min → 2 hr 25 min = +22 min) ( "Rollup of 8 pull requests") (2 hr 25 min → 2 hr 33 min = +8 min) ( "Optimize allocation paths in RawVec") (2 hr 33 min → 2 hr 50 min = +17 min) I'll check the detailed timing breakdown later. <details<summaryRaw timing data from AppVeyor</summary The raw data is extracted by running in the browser's console. </details
The cause is definitely (cc but arguably is doing the right thing. There are two noticeable change with build 4267: The non-full-deps test cases are all run twice, once for i686 and once for i586. This is because the job is configured as , and now respects . These tests occpied 43 minutes in build 4267. The takes a much longer time to build (6 seconds → 2 minutes). The other builds become slower probably only because AppVeyor was busier at that time. While this is correct to test both i586 and i686, this pushes the complete test time too close to 3 hours. If AppVeyor become really slow, the build will spuriously timeout and 3 hours are wasted. Is it a good idea to not test (since it is Tier 2)? <details<summaryDetailed timing breakdown</summary </details
Thanks so much for the detailed investigation here I... thought we were testing i586 all this time bug I guess not :(. I think we may have stopped testing awhile ago when we never detected a regression and wanted to get round 2 hours, so I think it's ok at the very least to go back to the status quo of not testing it. All in all I think it's ok to not be testing it. Ideally we'd test everything but we just don't always have the capacity to do so :(
Unfortunately the Macs and ARMs still take about 2.5 hours (not regression) .

Discussion:
RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-msvc --enable-profiler SCRIPT: python x.py test - MSYS_BITS: 32 <del> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc --target=i586-pc-windows-msvc </del> <ins> RUST_CONFIGURE_ARGS: --build=i686-pc-windows-msvc --target=i686-pc-windows-msvc </ins> SCRIPT: python x.py test --host i686-pc-windows-msvc --target i686-pc-windows-msvc # MSVC aux tests
Change:
This page isn’t working is currently unable to handle this request. HTTP ERROR 503
The bot got moved at some point; try Are there some docs that need to be updated?
Or how about made 302 redirect to the new target url?
Are there some docs that need to be updated? There are few references to the old address in the rust repo, including (all can be found by searching "buildbot").
Fixed the broken link in so I'm going to remove the issue tag here. It would be nice if there was a or something that was a GitHub Pages site that had an for and whatever else relevant resources for maintaining the queue. It'd be easy to change if the homu link changes again in the future.
I on IRC how to do this awhile ago, and I believe they're still basically applicable today. If anyone would like to help implement this and still has questions please just let me know!

Discussion:
[tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ [ro]: http://www.rustaceans.org/ [rctd]: ./src/test/COMPILER_TESTS.md <del> [cheatsheet]: https://buildbot.rust-lang.org/homu/ </del> <ins> [cheatsheet]: https://buildbot2.rust-lang.org/homu/ </ins>
Change:
Please rerun as: to show the backtrace.
backtrace:
Just some unwrap-happy parsing code at - needs to report a proper error when it can't parse user input (proper syntax is ).

Discussion:
let cfg = items.iter().find(|k| { k.check_name("cfg") }).and_then(|a| a.meta_item_list()); <del> let cfg = cfg.map(|list| { list[0].meta_item().unwrap().clone() }); </del> <ins> let cfg = if let Some(list) = cfg { if list.is_empty() { self.tcx.sess.span_err(m.span(), "`cfg()` must have an argument"); return; } else if let cfg @ Some(..) = list[0].meta_item() { cfg.cloned() } else { self.tcx.sess.span_err(list[0].span(), "invalid argument for `cfg(..)`"); return; } } else { None }; </ins> let foreign_items = fm.items.iter() .map(|it| self.tcx.hir.local_def_id(it.id)) .collect();

<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. #![feature(attr_literals)] #[link(name="foo", cfg("rlib"))] //~ ERROR invalid argument for `cfg(..)` extern {} fn main() {} </ins>

<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. #[link(name="foo", cfg())] //~ ERROR `cfg()` must have an argument extern {} fn main() {} </ins>
Change:
Contains messages like Possible cause:
Seems no longer happen. Will close once all linked PRs are merged.
IIRC this isn't the first time this has happened. We should probably just mirror whatever we need locally in our S3 mirror. If someone's willing to figure out how to change the build to not hit but hit a custom download, I'd be more than willing to upload some artifacts!

Discussion:
# - set PATH=%PATH%;%CD% -- this already happens above for sccache # Install InnoSetup to get `iscc` used to produce installers <del> - appveyor-retry choco install -y InnoSetup </del> <ins> - appveyor-retry appveyor DownloadFile https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-08-22-is.exe - 2017-08-22-is.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- </ins> - set PATH="C:Program Files (x86)Inno Setup 5";%PATH% # Help debug some handle issues on AppVeyor
Change:
EDIT: also
Without consent from there might be license issues, as rust docs are under the Apache2/MIT dual license and stack overflow posts are CC-BY-SA.
I am perfectly happy to give consent, and for the content to be reused in whole or in parts, altered or not, and without citation (as it would I think disturb the flow of reading).
Hi there! I would love to help work on this bug if it's still available!
yep, it's still available! if you have any questions or need any help, don't hesitate to ask!
did you make any progress on this or is it open for someone else to start work on it?
Unfortunately I wasn't able to - please open it for other individuals to take a shot
If its ok I would like to do this
Sounds great If you want any help or don't know where to start or have any questions, don't hesitate to ask!

Discussion:
//! Shareable mutable containers. //! <ins> //! Rust memory safety is based on this rule: Given an object `T`, it is only possible to //! have one of the following: //! //! - Having several immutable references (`&T`) to the object (also known as **aliasing**). //! - Having one mutable reference (`&mut T`) to the object (also known as **mutability**). //! //! This is enforced by the Rust compiler. However, there are situations where this rule is not //! flexible enough. Sometimes it is required to have multiple references to an object and yet //! mutate it. //! //! Shareable mutable containers exist to permit mutability in a controlled manner, even in the //! presence of aliasing. Both `Cell<T>` and `RefCell<T>` allows to do this in a single threaded //! way. However, neither `Cell<T>` nor `RefCell<T>` are thread safe (they do not implement //! `Sync`). If you need to do aliasing and mutation between multiple threads it is possible to //! use [`Mutex`](../../std/sync/struct.Mutex.html), //! [`RwLock`](../../std/sync/struct.RwLock.html) or //! [`atomic`](../../core/sync/atomic/index.html) types. //! </ins> //! Values of the `Cell<T>` and `RefCell<T>` types may be mutated through shared references (i.e. //! the common `&T` type), whereas most Rust types can only be mutated through unique (`&mut T`) //! references. We say that `Cell<T>` and `RefCell<T>` provide 'interior mutability', in contrast