jiebi/CodeConvo huggingface dataset:
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> // 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. #include "llvm/Linker/Linker.h" #include "rustllvm.h" using namespace llvm; struct RustLinker { Linker L; LLVMContext &Ctx; RustLinker(Module &M) : L(M), Ctx(M.getContext()) {} }; extern "C" RustLinker* LLVMRustLinkerNew(LLVMModuleRef DstRef) { Module *Dst = unwrap(DstRef); auto Ret = llvm::make_unique<RustLinker>(*Dst); return Ret.release(); } extern "C" void LLVMRustLinkerFree(RustLinker *L) { delete L; } extern "C" bool LLVMRustLinkerAdd(RustLinker *L, char *BC, size_t Len) { std::unique_ptr<MemoryBuffer> Buf = MemoryBuffer::getMemBufferCopy(StringRef(BC, Len)); #if LLVM_VERSION_GE(4, 0) Expected<std::unique_ptr<Module>> SrcOrError = llvm::getLazyBitcodeModule(Buf->getMemBufferRef(), L->Ctx); if (!SrcOrError) { LLVMRustSetLastError(toString(SrcOrError.takeError()).c_str()); return false; } auto Src = std::move(*SrcOrError); #else ErrorOr<std::unique_ptr<Module>> Src = llvm::getLazyBitcodeModule(std::move(Buf), L->Ctx); if (!Src) { LLVMRustSetLastError(Src.getError().message().c_str()); return false; } #endif #if LLVM_VERSION_GE(4, 0) if (L->L.linkInModule(std::move(Src))) { #else if (L->L.linkInModule(std::move(Src.get()))) { #endif LLVMRustSetLastError(""); return false; } return true; } </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: } } <del> extern "C" bool LLVMRustLinkInExternalBitcode(LLVMModuleRef DstRef, char *BC, size_t Len) { Module *Dst = unwrap(DstRef); std::unique_ptr<MemoryBuffer> Buf = MemoryBuffer::getMemBufferCopy(StringRef(BC, Len)); #if LLVM_VERSION_GE(4, 0) Expected<std::unique_ptr<Module>> SrcOrError = llvm::getLazyBitcodeModule(Buf->getMemBufferRef(), Dst->getContext()); if (!SrcOrError) { LLVMRustSetLastError(toString(SrcOrError.takeError()).c_str()); return false; } auto Src = std::move(*SrcOrError); #else ErrorOr<std::unique_ptr<Module>> Src = llvm::getLazyBitcodeModule(std::move(Buf), Dst->getContext()); if (!Src) { LLVMRustSetLastError(Src.getError().message().c_str()); return false; } #endif std::string Err; raw_string_ostream Stream(Err); DiagnosticPrinterRawOStream DP(Stream); #if LLVM_VERSION_GE(4, 0) if (Linker::linkModules(*Dst, std::move(Src))) { #else if (Linker::linkModules(*Dst, std::move(Src.get()))) { #endif LLVMRustSetLastError(Err.c_str()); return false; } return true; } </del> // Note that the two following functions look quite similar to the // LLVMGetSectionName function. Sadly, it appears that this function only // returns a char* pointer, which isn't guaranteed to be null-terminated. The
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: FileType(self.0.file_type()) } <del> /// Returns whether this metadata is for a directory. </del> <ins> /// Returns whether this metadata is for a directory. The /// result is mutually exclusive to the result of /// [`is_file`], and will be false for symlink metadata /// obtained from [`symlink_metadata`]. /// /// [`is_file`]: struct.Metadata.html#method.is_file /// [`symlink_metadata`]: fn.symlink_metadata.html </ins> /// /// # Examples ///
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] pub fn is_dir(&self) -> bool { self.file_type().is_dir() } <del> /// Returns whether this metadata is for a regular file. </del> <ins> /// Returns whether this metadata is for a regular file. The /// result is mutually exclusive to the result of /// [`is_dir`], and will be false for symlink metadata /// obtained from [`symlink_metadata`]. /// /// [`is_dir`]: struct.Metadata.html#method.is_dir /// [`symlink_metadata`]: fn.symlink_metadata.html </ins> /// /// # Examples ///
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: } impl FileType { <del> /// Test whether this file type represents a directory. </del> <ins> /// Test whether this file type represents a directory. The /// result is mutually exclusive to the results of /// [`is_file`] and [`is_symlink`]; only zero or one of these /// tests may pass. /// /// [`is_file`]: struct.FileType.html#method.is_file /// [`is_symlink`]: struct.FileType.html#method.is_symlink </ins> /// /// # Examples ///
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: pub fn is_dir(&self) -> bool { self.0.is_dir() } /// Test whether this file type represents a regular file. <ins> /// The result is  mutually exclusive to the results of /// [`is_dir`] and [`is_symlink`]; only zero or one of these /// tests may pass. /// /// [`is_dir`]: struct.FileType.html#method.is_dir /// [`is_symlink`]: struct.FileType.html#method.is_symlink </ins> /// /// # Examples ///
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: pub fn is_file(&self) -> bool { self.0.is_file() } /// Test whether this file type represents a symbolic link. <ins> /// The result is mutually exclusive to the results of /// [`is_dir`] and [`is_file`]; only zero or one of these /// tests may pass. </ins> /// /// The underlying [`Metadata`] struct needs to be retrieved /// with the [`fs::symlink_metadata`] function and not the
Code change:
should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.

Related discussion:
text: /// [`Metadata`]: struct.Metadata.html /// [`fs::metadata`]: fn.metadata.html /// [`fs::symlink_metadata`]: fn.symlink_metadata.html <ins> /// [`is_dir`]: struct.FileType.html#method.is_dir /// [`is_file`]: struct.FileType.html#method.is_file </ins> /// [`is_symlink`]: struct.FileType.html#method.is_symlink /// /// # Examples
Code change:
This ICEs with 'tyregion() invoked on in appropriate ty: tybot' from Full output from : Sorry for making the poor compiler throw up with my bad code. :(
"Sorry for putting in effort to make your compiler better with no personal gain", you mean! :-D
Can't reproduce this anymore.

Related discussion:
text: #[lang="return_to_mut"] #[inline(always)] pub unsafe fn return_to_mut(a: *u8) { <del> let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; </del> <ins> // Sometimes the box is null, if it is conditionally frozen. // See e.g. #4904. if !a.is_null() { let a: *mut BoxRepr = transmute(a); (*a).header.ref_count &= !FROZEN_BIT; } </ins> } #[lang="check_not_borrowed"]
Code change:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

Related discussion:
text: /// [`ancestors`]: struct.Path.html#method.ancestors /// [`Path`]: struct.Path.html #[derive(Copy, Clone, Debug)] <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> pub struct Ancestors<'a> { next: Option<&'a Path>, } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> Iterator for Ancestors<'a> { type Item = &'a Path;
Code change:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

Related discussion:
text: } } <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> impl<'a> FusedIterator for Ancestors<'a> {} ////////////////////////////////////////////////////////////////////////////////
Code change:
Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc

Related discussion:
text: /// /// [`None`]: ../../std/option/enum.Option.html#variant.None /// [`parent`]: struct.Path.html#method.parent <del> #[unstable(feature = "path_ancestors", issue = "48581")] </del> <ins> #[stable(feature = "path_ancestors", since = "1.28.0")] </ins> pub fn ancestors(&self) -> Ancestors { Ancestors { next: Some(&self),
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

Related discussion:
text: use ich::{self, CachingCodemapView, Fingerprint}; use middle::cstore::CrateStore; use ty::{TyCtxt, fast_reject}; <ins> use mir::interpret::AllocId; </ins> use session::Session; use std::cmp::Ord;
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

Related discussion:
text: // CachingCodemapView, so we initialize it lazily. raw_codemap: &'a CodeMap, caching_codemap: Option<CachingCodemapView<'a>>, <ins> pub(super) alloc_id_recursion_tracker: FxHashSet<AllocId>, </ins> } #[derive(PartialEq, Eq, Clone, Copy)]
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

Related discussion:
text: hash_spans: hash_spans_initial, hash_bodies: true, node_id_hashing_mode: NodeIdHashingMode::HashDefPath, <ins> alloc_id_recursion_tracker: Default::default(), </ins> } }
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

Related discussion:
text: }); enum AllocDiscriminant { <del> Static, Constant, </del> <ins> Alloc, ExternStatic, </ins> Function, } impl_stable_hash_for!(enum self::AllocDiscriminant { <del> Static, Constant, </del> <ins> Alloc, ExternStatic, </ins> Function });
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

Related discussion:
text: ) { ty::tls::with_opt(|tcx| { let tcx = tcx.expect("can't hash AllocIds during hir lowering"); <del> if let Some(def_id) = tcx.interpret_interner.get_corresponding_static_def_id(*self) { AllocDiscriminant::Static.hash_stable(hcx, hasher); // statics are unique via their DefId def_id.hash_stable(hcx, hasher); } else if let Some(alloc) = tcx.interpret_interner.get_alloc(*self) { // not a static, can't be recursive, hash the allocation AllocDiscriminant::Constant.hash_stable(hcx, hasher); alloc.hash_stable(hcx, hasher); </del> <ins> if let Some(alloc) = tcx.interpret_interner.get_alloc(*self) { AllocDiscriminant::Alloc.hash_stable(hcx, hasher); if !hcx.alloc_id_recursion_tracker.insert(*self) { tcx .interpret_interner .get_corresponding_static_def_id(*self) .hash_stable(hcx, hasher); alloc.hash_stable(hcx, hasher); assert!(hcx.alloc_id_recursion_tracker.remove(self)); } </ins> } else if let Some(inst) = tcx.interpret_interner.get_fn(*self) { AllocDiscriminant::Function.hash_stable(hcx, hasher); inst.hash_stable(hcx, hasher); <ins> } else if let Some(def_id) = tcx.interpret_interner .get_corresponding_static_def_id(*self) { AllocDiscriminant::ExternStatic.hash_stable(hcx, hasher); def_id.hash_stable(hcx, hasher); </ins> } else { bug!("no allocation for {}", self); }
Code change:
The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.

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. // https://github.com/rust-lang/rust/issues/49081 // revisions:rpass1 rpass2 #[cfg(rpass1)] pub static A: &str = "hello"; #[cfg(rpass2)] pub static A: &str = "xxxxx"; #[cfg(rpass1)] fn main() { assert_eq!(A, "hello"); } #[cfg(rpass2)] fn main() { assert_eq!(A, "xxxxx"); } </ins>
Code change:
Documentation on states: However, this code panics on both store and load (if the call to store() is commented out) Either documentation should be updated to describe why this is not relevant to store/load, or implementation should be fixed to actually deliver on the promise.
The implementation is correct. AcquireRelease is an ordering for operations that both load and store. If you just have a load or a store, you can and should simply use acquire or release respectively.
Ok, makes sense. Then the documentation should reflect that more clearly.

Related discussion:
text: /// [`Release`]: http://llvm.org/docs/Atomics.html#release #[stable(feature = "rust1", since = "1.0.0")] Acquire, <del> /// When coupled with a load, uses [`Acquire`] ordering, and with a store /// [`Release`] ordering. </del> <ins> /// Has the effects of both [`Acquire`] and [`Release`] together. /// /// This ordering is only applicable for operations that combine both loads and stores. /// /// For loads it uses [`Acquire`] ordering. For stores it uses the [`Release`] ordering. </ins> /// /// [`Acquire`]: http://llvm.org/docs/Atomics.html#acquire /// [`Release`]: http://llvm.org/docs/Atomics.html#release
Code change:
Nobody responded to , and the rabbit hole has only gotten deeper and deeper since I've started trying to work around this . It's time for an issue. Here's a simple pattern macro: Trouble is, suppose somebody writes . Then they'll get this: Here is the simplest alternative I can come up with for working around this warning in this simple macro. Notice how proper support for and requires that the macro output uses shorthand field syntax, as opposed to a more scalable workaround like (where the is at least something that could be produced by a helper macro). A similar pattern macro for a struct with two fields basically requires an incremental muncher now, just to avoid the exponential blowup of rules. This is an awful lot of headache just for a little reminder to write more idiomatic code! Isn't that clippy's job, anyhow?
A crude fix would be to just not trigger this lint in macro expansions (at the cost of missing out on linting macro code where the offending non-shorthand pattern doesn't come as an argument, which, ideally, should be linted):

Related discussion:
text: } if let PatKind::Binding(_, _, name, None) = fieldpat.node.pat.node { if name.node == fieldpat.node.name { <ins> if let Some(_) = fieldpat.span.ctxt().outer().expn_info() { // Don't lint if this is a macro expansion: macro authors // shouldn't have to worry about this kind of style issue // (Issue #49588) return; } </ins> let mut err = cx.struct_span_lint(NON_SHORTHAND_FIELD_PATTERNS, fieldpat.span, &format!("the `{}:` in this pattern is redundant",