jiebi/CodeConvo huggingface dataset:
Code change:
Originally reported here: I don't understand the following sentence: Could someone parse this for me? To me, it reads like "to free memory allocated by a Vec v, create a new Vec w and drop it (i.e., w)". This is obviously not what it is intended. What's the role of the second Vec? Is this only in a context where v is empty but its memory not yet freed? If so, why wouldn't shrinktofit work in that case?
This refers to unsafe code that e.g. uses to allocate memory, and then s the to use the buffer in different ways (e.g., passing it to C, or implement a custom data structure over the allocated memory).

Related discussion:
text: /// types inside a `Vec`, it will not allocate space for them. *Note that in this case /// the `Vec` may not report a [`capacity`] of 0*. `Vec` will allocate if and only /// if [`mem::size_of::<T>`]`() * capacity() > 0`. In general, `Vec`'s allocation <del> /// details are subtle enough that it is strongly recommended that you only /// free memory allocated by a `Vec` by creating a new `Vec` and dropping it. </del> <ins> /// details are very subtle &mdash; if you intend to allocate memory using a `Vec` /// and use it for something else (either to pass to unsafe code, or to build your /// own memory-backed collection), be sure to deallocate this memory by using /// `from_raw_parts` to recover the `Vec` and then dropping it. </ins> /// /// If a `Vec` *has* allocated memory, then the memory it points to is on the heap /// (as defined by the allocator Rust is configured to use by default), and its
Code change:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:

Related discussion:
text: end: RangeEnd, }, <del> /// matches against a slice, checking the length and extracting elements </del> <ins> /// matches against a slice, checking the length and extracting elements. /// irrefutable when there is a slice pattern and both `prefix` and `suffix` are empty. /// e.g. `&[ref xs..]`. </ins> Slice { prefix: Vec<Pattern<'tcx>>, slice: Option<Pattern<'tcx>>,
Code change:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:

Related discussion:
text: Err(match_pair) } <del> PatternKind::Range { .. } | PatternKind::Slice { .. } => { </del> <ins> PatternKind::Range { .. } => { </ins> Err(match_pair) } <ins> PatternKind::Slice { ref prefix, ref slice, ref suffix } => { if prefix.is_empty() && slice.is_some() && suffix.is_empty() { // irrefutable self.prefix_slice_suffix(&mut candidate.match_pairs, &match_pair.place, prefix, slice.as_ref(), suffix); Ok(()) } else { Err(match_pair) } } </ins> PatternKind::Variant { adt_def, substs, variant_index, ref subpatterns } => { let irrefutable = adt_def.variants.iter().enumerate().all(|(i, v)| { i == variant_index || {
Code change:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #47096 #![feature(slice_patterns)] fn foo(s: &[i32]) -> &[i32] { let &[ref xs..] = s; xs } fn main() { let x = [1, 2, 3]; let y = foo(&x); assert_eq!(x, y); } </ins>
Code change:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

Related discussion:
text: #[test] #[should_fail] fn test_ascii_fail_char_slice() { 'λ'.to_ascii(); } <ins> #[test] </ins> fn test_opt() { assert_eq!(65u8.to_ascii_opt(), Some(Ascii { chr: 65u8 })); assert_eq!(255u8.to_ascii_opt(), None);
Code change:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

Related discussion:
text: #[cfg(test)] mod test { use super::*; <del> use io::net::ip::{Ipv4Addr, SocketAddr}; </del> <ins> use io::net::ip::{SocketAddr}; </ins> use io::*; <del> use io::test::*; </del> use prelude::*; iotest!(fn bind_error() {
Code change:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

Related discussion:
text: use unstable::run_in_bare_thread; use super::*; use rt::task::Task; <del> use rt::local_ptr; </del> #[test] fn thread_local_task_smoke_test() {
Code change:
Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.

Related discussion:
text: fn visit_estr_uniq(&mut self) -> bool { true } fn visit_estr_slice(&mut self) -> bool { true } fn visit_estr_fixed(&mut self, <del> _sz: uint, _sz: uint, </del> <ins> _sz: uint, _sz2: uint, </ins> _align: uint) -> bool { true } fn visit_box(&mut self, _mtbl: uint, _inner: *TyDesc) -> bool { true }
Code change:
The code around opt-levels indicates only nightly can use or . Non-nightly s should not even report those values as possible options.

Related discussion:
text: } OptLevel::Default } else { <del> match ( cg.opt_level.as_ref().map(String::as_ref), nightly_options::is_nightly_build(), ) { (None, _) => OptLevel::No, (Some("0"), _) => OptLevel::No, (Some("1"), _) => OptLevel::Less, (Some("2"), _) => OptLevel::Default, (Some("3"), _) => OptLevel::Aggressive, (Some("s"), true) => OptLevel::Size, (Some("z"), true) => OptLevel::SizeMin, (Some("s"), false) | (Some("z"), false) => { early_error( error_format, &format!( "the optimizations s or z are only  accepted on the nightly compiler" ), ); } (Some(arg), _) => { </del> <ins> match cg.opt_level.as_ref().map(String::as_ref) { None => OptLevel::No, Some("0") => OptLevel::No, Some("1") => OptLevel::Less, Some("2") => OptLevel::Default, Some("3") => OptLevel::Aggressive, Some("s") => OptLevel::Size, Some("z") => OptLevel::SizeMin, Some(arg) => { </ins> early_error( error_format, &format!(
Code change:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .

Related discussion:
text: pub use run::{cmd, run, run_fail, run_with_args}; /// Helpers for checking target information. <del> pub use targets::{is_darwin, is_msvc, is_windows, llvm_components_contain, target, uname}; </del> <ins> pub use targets::{is_darwin, is_msvc, is_windows, llvm_components_contain, target, uname, apple_os}; </ins> /// Helpers for building names of output artifacts that are potentially target-specific. pub use artifact_names::{
Code change:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .

Related discussion:
text: target().contains("darwin") } <ins> /// Get the target OS on Apple operating systems. #[must_use] pub fn apple_os() -> &'static str { if target().contains("darwin") { "macos" } else if target().contains("ios") { "ios" } else if target().contains("tvos") { "tvos" } else if target().contains("watchos") { "watchos" } else if target().contains("visionos") { "visionos" } else { panic!("not an Apple OS") } } </ins> /// Check if `component` is within `LLVM_COMPONENTS` #[must_use] pub fn llvm_components_contain(component: &str) -> bool {
Code change:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .

Related discussion:
text: run-make/issue-84395-lto-embed-bitcode/Makefile run-make/jobserver-error/Makefile run-make/libs-through-symlinks/Makefile <del> run-make/macos-deployment-target/Makefile </del> run-make/split-debuginfo/Makefile run-make/symbol-mangling-hashed/Makefile run-make/translation/Makefile
Code change:
Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .

Related discussion:
text: <del> # only-macos # # Check that a set deployment target actually makes it to the linker. # This is important since its a compatibility hazard. The linker will # generate load commands differently based on what minimum OS it can assume. include ../tools.mk ifeq ($(strip $(shell uname -m)),arm64) GREP_PATTERN = "minos 11.0" else GREP_PATTERN = "version 10.13" endif OUT_FILE=$(TMPDIR)/with_deployment_target.dylib all: env MACOSX_DEPLOYMENT_TARGET=10.13 $(RUSTC) with_deployment_target.rs -o $(OUT_FILE) # XXX: The check is for either the x86_64 minimum OR the aarch64 minimum (M1 starts at macOS 11). # They also use different load commands, so we let that change with each too. The aarch64 check # isn't as robust as the x86 one, but testing both seems unneeded. vtool -show-build $(OUT_FILE) | $(CGREP) -e $(GREP_PATTERN) </del>
Code change:
is implemented for Range<T. TrustedLen that the upper bound of is None if the iterator produces more than elements. to produce its result. The of subtracts the lower from the upper value and casts it to usize. This is for u32. On 16bit platforms, the result of the subtraction of two u32 values may not fit inside , producing an invalid . This means, that e.g. collecting into a Vec using its allows writing beyond its reserved buffer. One such example input would be . Reference: /cc

Related discussion:
text: )*) } <del> step_impl_unsigned!(usize u8 u16 u32); step_impl_signed!([isize: usize] [i8: u8] [i16: u16] [i32: u32]); </del> <ins> step_impl_unsigned!(usize u8 u16); #[cfg(not(target_pointer_witdth = "16"))] step_impl_unsigned!(u32); #[cfg(target_pointer_witdth = "16")] step_impl_no_between!(u32); step_impl_signed!([isize: usize] [i8: u8] [i16: u16]); #[cfg(not(target_pointer_witdth = "16"))] step_impl_signed!([i32: u32]); #[cfg(target_pointer_witdth = "16")] step_impl_no_between!(i32); </ins> #[cfg(target_pointer_width = "64")] step_impl_unsigned!(u64); #[cfg(target_pointer_width = "64")]
Code change:
is implemented for Range<T. TrustedLen that the upper bound of is None if the iterator produces more than elements. to produce its result. The of subtracts the lower from the upper value and casts it to usize. This is for u32. On 16bit platforms, the result of the subtraction of two u32 values may not fit inside , producing an invalid . This means, that e.g. collecting into a Vec using its allows writing beyond its reserved buffer. One such example input would be . Reference: /cc

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(step_trait)] use std::iter::Step; #[cfg(target_pointer_width = "16")] fn main() { assert!(Step::steps_between(&0u32, &::std::u32::MAX).is_none()); } #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] fn main() { assert!(Step::steps_between(&0u32, &::std::u32::MAX).is_some()); } </ins>
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: cfg.file("../rustllvm/PassWrapper.cpp") .file("../rustllvm/RustWrapper.cpp") .file("../rustllvm/ArchiveWrapper.cpp") <ins> .file("../rustllvm/Linker.cpp") </ins> .cpp(true) .cpp_link_stdlib(None) // we handle this below .compile("rustllvm");
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: #[allow(missing_copy_implementations)] pub enum OperandBundleDef_opaque {} pub type OperandBundleDefRef = *mut OperandBundleDef_opaque; <ins> #[allow(missing_copy_implementations)] pub enum Linker_opaque {} pub type LinkerRef = *mut Linker_opaque; </ins> pub type DiagnosticHandler = unsafe extern "C" fn(DiagnosticInfoRef, *mut c_void); pub type InlineAsmDiagHandler = unsafe extern "C" fn(SMDiagnosticRef, *const c_void, c_uint);
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: pub fn LLVMRustPrintPasses(); pub fn LLVMRustSetNormalizedTarget(M: ModuleRef, triple: *const c_char); pub fn LLVMRustAddAlwaysInlinePass(P: PassManagerBuilderRef, AddLifetimes: bool); <del> pub fn LLVMRustLinkInExternalBitcode(M: ModuleRef, bc: *const c_char, len: size_t) -> bool; </del> pub fn LLVMRustRunRestrictionPass(M: ModuleRef, syms: *const *const c_char, len: size_t); pub fn LLVMRustMarkAllFunctionsNounwind(M: ModuleRef);
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: CU2: *mut *mut c_void); pub fn LLVMRustThinLTOPatchDICompileUnit(M: ModuleRef, CU: *mut c_void); pub fn LLVMRustThinLTORemoveAvailableExternally(M: ModuleRef); <ins> pub fn LLVMRustLinkerNew(M: ModuleRef) -> LinkerRef; pub fn LLVMRustLinkerAdd(linker: LinkerRef, bytecode: *const c_char, bytecode_len: usize) -> bool; pub fn LLVMRustLinkerFree(linker: LinkerRef); </ins> }
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: // know much about the memory management here so we err on the side of being // save and persist everything with the original module. let mut serialized_bitcode = Vec::new(); <ins> let mut linker = Linker::new(llmod); </ins> for (bc_decoded, name) in serialized_modules { info!("linking {:?}", name); <del> time(cgcx.time_passes, &format!("ll link {:?}", name), || unsafe { </del> <ins> time(cgcx.time_passes, &format!("ll link {:?}", name), || { </ins> let data = bc_decoded.data(); <del> if llvm::LLVMRustLinkInExternalBitcode(llmod, data.as_ptr() as *const libc::c_char, data.len() as libc::size_t) { Ok(()) } else { </del> <ins> linker.add(&data).map_err(|()| { </ins> let msg = format!("failed to load bc of {:?}", name); <del> Err(write::llvm_err(&diag_handler, msg)) } </del> <ins> write::llvm_err(&diag_handler, msg) }) </ins> })?; timeline.record(&format!("link {:?}", name)); serialized_bitcode.push(bc_decoded); } <ins> drop(linker); </ins> cgcx.save_temp_bitcode(&module, "lto.input"); // Internalize everything that *isn't* in our whitelist to help strip out
Code change:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet

Related discussion:
text: }]) } <ins> struct Linker(llvm::LinkerRef); impl Linker { fn new(llmod: ModuleRef) -> Linker { unsafe { Linker(llvm::LLVMRustLinkerNew(llmod)) } } fn add(&mut self, bytecode: &[u8]) -> Result<(), ()> { unsafe { if llvm::LLVMRustLinkerAdd(self.0, bytecode.as_ptr() as *const libc::c_char, bytecode.len()) { Ok(()) } else { Err(()) } } } } impl Drop for Linker { fn drop(&mut self) { unsafe { llvm::LLVMRustLinkerFree(self.0); } } } </ins> /// Prepare "thin" LTO to get run on these modules. /// /// The general structure of ThinLTO is quite different from the structure of