jiebi/CodeConvo huggingface dataset:
Change:
LL | LL |   impl IntoPyDictPointer for () |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `()` <ins> | = note: upstream crates may add new impl of trait `std::iter::Iterator` for type `()` in future versions </ins> error: aborting due to previous error

Discussion:
PR had removed the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: Plus, the new error messages are worse: an upstream impl can indeed be , even if the crate is private. I think that even in the OP case, some sort of note should be , unless we change coherence. Again, the test case: There, the error message is a coherence conflict for , where this impl conflicts with the libcore impl, because the compiler can't prove that . Now, the error message says that the reason that the compiler can't prove is because of a possible downstream impl. Of course, no downstream impl can exist as the trait is private, however, I don't think we want to change coherence to account for that, especially not without an RFC. Maybe a wording change is in order? I don't think the "upstream" message needs to change any (see the test diff), it's still good in the private case. Maybe it should try to mention a non-private trait, but that would be some work. Say, for non-exported trait, change the note to say: I'm not even sure the note is a problem, I personally like the state before the PR the best. cc
Actually, I think the version of the note I came up with is even more confusing than the "downstream crate" note, and the current version is worse than both.
That PR was also submitted with no "positive" test to see that it fixes the error message it is purported to fix. That feels clearly wrong to me.
Change:
} } <del> pub unsafe fn cleanup() { let args = ARGS.swap(0, Ordering::Relaxed); if args != 0 { drop(Box::<ArgsStore>::from_raw(args as _)) } } </del> <ins> pub unsafe fn cleanup() {} </ins> pub fn args() -> Args { let args = unsafe { (ARGS.load(Ordering::Relaxed) as *const ArgsStore).as_ref() };

Discussion:
The method is defined as follows. Clean-up function is defined as follows; It is possible for another thread to use while the main thread quits, and access already freed memory - assuming the following sequence of events. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc (do we want an label?)
I suppose we could just turn into a NOP. How do other platforms handle this?
claim
Looking at other implementations, the only times when this is not a NOP is for and on non-apple variants. In all these cases the code is: I am inclined to just change it to a NOP. What was the motivation for the existing logic?
Implement the required function without knowing exactly what needs to happen. Having done some git archeology, it looks to me like the function exists solely for certain platforms where the arguments may be stored on the stack of the main thread. If the main thread exits, that stack may no longer be available so other threads may not reference it. I think turning it into a nop for SGX is probably fine.
Change:
use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_middle::{ hir::place::PlaceBase, <del> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, Location}, </del> <ins> mir::{self, ClearCrossCrate, Local, LocalDecl, LocalInfo, LocalKind, Location}, </ins> }; use rustc_span::source_map::DesugaringKind; use rustc_span::symbol::{kw, Symbol};

Discussion:
Summary: The compiler suggests changing to when trying to modify in a method. For trait implemantions this does not work because it would require changing the trait definition too (which is often not possible). Example: I was trying to implement the trait from the standard library for a custom type: () This of course doesn't work since you can't modify data behind a reference: However, I noticed that the help message suggests changing the to , which is incorrect since that would require changing the trait definition in the standard library too. Suggestion: I don't know if this is possible, but maybe this help message should only be shown for "normal" methods and hidden when implementing trait methods?
Maybe only hide the suggestion if the trait comes from a foreign crate?
Or suggest to change the trait (if it is in this crate) not change the function in the part.
One more idea: suggest ///
Change:
fn take_element(&mut self) -> Option<A> { if self.count > 0 { self.count = 0; <ins> let element = mem::replace(&mut self.element, MaybeUninit::uninit()); </ins> // SAFETY: We just set count to zero so it won't be dropped again, // and it used to be non-zero so it hasn't already been dropped. <del> unsafe { Some(ManuallyDrop::take(&mut self.element)) } </del> <ins> unsafe { Some(element.assume_init()) } </ins> } else { None }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --This is technically different from as there's no UAF. However, using with has undefined behavior if you use the last/original element after moving the iterator, since the field has noalias properties. <details<summaryMiri Backtrace</summary<p</p</detailsWrapping the element using (or once we have that) should make this sound.
See also:
The minimal example is actually this: Because eagerly calls drop for . This basically boils down to Which is indeed I quite strongly think that this is a bug in miri and/or ( should use inside of itself probably?). That being said this is not yet decided (again, see the UCG issue) :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Yeah, it should -- someone just has to implement first. ;) See
I tweaked the title because while there is an experimental Miri flag to make Unique magical, codegen only has special treatment for Box.

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --currently unconditionally derives . However, it will also drop its inner object if is 0, which can cause a UAF if it's cloned afterwards. Running the above program segfaults: Edit: Made the segfault quicker/more reliable.
same issue with its implementation
cc I think you implemented this. ^^
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
<ins> error: C-variadic function must be declared with at least one named argument --> $DIR/variadic-ffi-no-fixed-args.rs:2:11 | LL |     fn foo(...); |           ^ error: aborting due to previous error </ins>

Discussion:
This ICEs (see title) because of the call: That's because the definition of errored in 1.34, but doesn't since 1.35: cc (found while working on )
<details<summaryBacktrace</summary</details
Ah, the problem is that this wasn't updated ( now contains a ): Thankfully, at the same time, the ICE was , so calls wouldn't have been possible to such functions.
Good catch
Change:
PathSegment, Primitive, PrimitiveType, Type, TypeBinding, Visibility, }; use crate::core::DocContext; <del> use crate::formats::item_type::ItemType; </del> use rustc_ast as ast; use rustc_ast::tokenstream::TokenTree;

Discussion:
Run on this and get an ICE. Note that documenting itself does not panic, and that the is necessary. <!-- 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. --: Also reproduces on Linux (GitHub Actions) with the same nightly version. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc -T-compiler
It looks like this started after commit . () I was able to create a MCVE: <details<summaryBacktrace:</summary</details
cc
Further minimized: The issue disappears if the private is removed. Looks like some logic in rustdoc is over-eager to pull in stuff through private imports, links in 's methods are not visible in the generated documentation and shouldn't be resolved at all.
--are responsible for including the trait into the rustdoc's crate representation, still unclear why.
Fixed in
Change:
fn validate_place(&self, place: PlaceRef<'tcx>) -> Result<(), Unpromotable> { match place { PlaceRef { local, projection: [] } => self.validate_local(local), <del> PlaceRef { local: _, projection: [proj_base @ .., elem] } => { </del> <ins> PlaceRef { local, projection: [proj_base @ .., elem] } => { </ins> match *elem { <del> ProjectionElem::Deref | ProjectionElem::Downcast(..) => { </del> <ins> ProjectionElem::Deref => { let mut not_promotable = true; // This is a special treatment for cases like *&STATIC where STATIC is a // global static variable. // This pattern is generated only when global static variables are directly // accessed and is qualified for promotion safely. if let TempState::Defined { location, .. } = self.temps[local] { let def_stmt = self.body[location.block].statements.get(location.statement_index); if let Some(Statement { kind: StatementKind::Assign(box (_, Rvalue::Use(Operand::Constant(c)))), .. }) = def_stmt { if let Some(did) = c.check_static_ptr(self.tcx) { if let Some(hir::ConstContext::Static(..)) = self.const_kind { // The `is_empty` predicate is introduced to exclude the case // where the projection operations are [ .field, * ]. // The reason is because promotion will be illegal if field // accesses preceed the dereferencing. // Discussion can be found at // https://github.com/rust-lang/rust/pull/74945#discussion_r463063247 // There may be opportunity for generalization, but this needs to be // accounted for. if proj_base.is_empty() && !self.tcx.is_thread_local_static(did) { not_promotable = false; } } } } } if not_promotable { return Err(Unpromotable); } } ProjectionElem::Downcast(..) => { </ins> return Err(Unpromotable); }

Discussion:
The below code compiles in 1.40.0 but not in 1.42.0 (stable). (minimized example from rust-phf) When built in 1.42.0, it produces the following error: The same error occurs using nightly. There's an issue from January mentioning this build error on the rust-phf repo (seems to occur in 1.41.0+), but no followup discussion/work that I could find.
Notes: the same error occurs if is a struct instead of an enum the error does not occur if is removed and the is stored directly on
Minimized: must be a for this to happen, with a it doesn't happen.
This happens on both 1.41.0 and 1.41.1, so it's not fallout from (which fixed in that release). There's no entry in the release notes or blog post for 1.41.0 that indicates that this is expected fallout. cc anyways re: borrowck
regressed nightly: nightly-2019-11-24 searched commits: from to regressed commit: modify labels to -E-needs-bisection
Nice, thanks Looks like is the cause then.
assign
This issue was . Tagging as and unnominating.
So... the bug is fairly simple, albeit not easy to fix. The problem is that any use of a static anywhere like becomes This has various positive effects on rustc, making many implementation things easier, but it also means that it broke promoting reading from statics within other statics, because we will never ever support promoting &*STATICREFtmpSTATICREF`, so this is the special case we're allowed to deref.
Change:
<ins> // edition:2021 // check-pass #![feature(try_blocks)] #![feature(let_else)] fn main() { let _: Result<i32, i32> = try { let Some(x) = Some(0) else { Err(1)? }; x }; } </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
On a side note this is valid and compiles:
Yeah, this is very likely due to expr either not being recorded correctly when type-checking , or those not being used correctly when building MIR for . I will look into this later.
Minimized this a tiny bit: Still working on it though. Unrelated to try-blocks.
Change:
<ins> error[E0271]: type mismatch resolving `<dyn Trait<A = A, B = B> as SuperTrait>::A == B` --> $DIR/enforce-supertrait-projection.rs:9:5 | LL | fn transmute<A, B>(x: A) -> B { |              -  - expected type parameter |              | |              found type parameter LL |     foo::<A, B, dyn Trait<A = A, B = B>>(x) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected type parameter `B`, found type parameter `A` | = note: expected type parameter `B` found type parameter `A` = note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters note: required by a bound in `foo` --> $DIR/enforce-supertrait-projection.rs:15:8 | LL | fn foo<A, B, T: ?Sized>(x: T::A) -> B |    --- required by a bound in this LL | where LL |     T: Trait<B = B>, |        ^^^^^^^^^^^^ required by this bound in `foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
AR_loongarch64_unknown_linux_gnu=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_linux_gnu=loongarch64-unknown-linux-gnu-g++ <ins> # We re-use the Linux toolchain for bare-metal, because upstream bare-metal # target support for LoongArch is only available from GCC 14+. # # See: https://github.com/gcc-mirror/gcc/commit/976f4f9e4770 ENV CC_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-gcc  AR_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_none=loongarch64-unknown-linux-gnu-g++  CFLAGS_loongarch64_unknown_none="-ffreestanding -mabi=lp64d"  CXXFLAGS_loongarch64_unknown_none="-ffreestanding -mabi=lp64d"  CC_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-gcc  AR_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-ar  CXX_loongarch64_unknown_none_softfloat=loongarch64-unknown-linux-gnu-g++  CFLAGS_loongarch64_unknown_none_softfloat="-ffreestanding -mabi=lp64s -mfpu=none"  CXXFLAGS_loongarch64_unknown_none_softfloat="-ffreestanding -mabi=lp64s -mfpu=none" </ins> ENV HOSTS=loongarch64-unknown-linux-gnu <ins> ENV TARGETS=$HOSTS ENV TARGETS=$TARGETS,loongarch64-unknown-none ENV TARGETS=$TARGETS,loongarch64-unknown-none-softfloat </ins> ENV RUST_CONFIGURE_ARGS  --enable-extended 

Discussion:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc
Change:
// rustc-env:RUST_BACKTRACE=0 // normalize-stderr-test "note: rustc 1.* running on .*" -> "note: rustc VERSION running on TARGET" // normalize-stderr-test "note: compiler flags: .*" -> "note: compiler flags: FLAGS" <ins> // normalize-stderr-test "interpret/intern.rs:[0-9]*:[0-9]*" -> "interpret/intern.rs:LL:CC" </ins> #![allow(const_err)]

Discussion:
The build of smoltcp on nightly started failing recently with an ICE: https://travis- ~I suspect this might be caused by E0713, but it shouldn't be an ICE in any case.~
I believe the fundamental cause of the error is that the code looks like the following: That's pretty obviously unsound.
Correction for earlier comment: E0713 is completely unrelated. I've eliminated the problematic code that caused it in m-labs/smoltcp but the crash is still there.
cc (also, such an ICE should say "const checking" or similar - we should maybe even rename the pass itself in the compiler - the "qualify" part isn't as primary for MIR as it is for the AST side).
<details<summaryFull backtrace</summary</details<details<summaryfunction </summary</details
MCVE: : ok : ICE I'm bisecting it now.
Bisected to / .
Oh, I forgot about the ZST trickery, sorry, will have a fix tomorrow
What's the ZST here? in ?
Yes. That's a that gets unsized to .
Change:
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);

Discussion:
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
Change:
ty } <del> // Checks that the type of `expr` can be coerced to `expected`. // // N.B., this code relies on `self.diverges` to be accurate. In // particular, assignments to `!` will be permitted if the // diverges flag is currently "always". </del> <ins> /// Checks that the type of `expr` can be coerced to `expected`. /// /// N.B., this code relies on `self.diverges` to be accurate. In particular, assignments to `!` /// will be permitted if the diverges flag is currently "always". </ins> pub fn demand_coerce_diag( &self, expr: &hir::Expr<'_>,

Discussion:
Minimal example: The error is technically correct. I specified, that I want a box of F, but I create a closure. Because F is generic, it is caller-chosen and I create a new closure, which has a different type. Still, it took me quite some time to find out what was going on in the more complicated real code. I think that it would help to add a note here explaining, that each closure has a different type, and that the inner closure does not match the type F exactly. Maybe additionally a hint could be , stating to use instead (i.e. the traits F is bound to).
Current output: It doesn't handle the closure case in any special way, and it should.
I’m experiencing the same problem
Change:
define DEF_PREPARE <del> prepare-base-$(1)-%: PREPARE_SOURCE_DIR=$$(PREPARE_HOST)/stage$$(PREPARE_STAGE) prepare-base-$(1)-%: PREPARE_SOURCE_BIN_DIR=$$(PREPARE_SOURCE_DIR)/bin prepare-base-$(1)-%: PREPARE_SOURCE_LIB_DIR=$$(PREPARE_SOURCE_DIR)/$$(CFG_LIBDIR_RELATIVE) </del> prepare-base-$(1)-%: PREPARE_SOURCE_MAN_DIR=$$(S)/man prepare-base-$(1)-%: PREPARE_DEST_BIN_DIR=$$(PREPARE_DEST_DIR)/bin prepare-base-$(1)-%: PREPARE_DEST_LIB_DIR=$$(PREPARE_DEST_DIR)/$$(CFG_LIBDIR_RELATIVE)

Discussion:
There are no Windows nightlies currently being published: They appear to have been broken since at least Nov. 1. This prevents Servo from updating Rust. CC:
was looking into this earlier.
Change:
<del> //@ known-bug: rust-lang/rust#129205 fn x<T: Copy>() { T::try_from(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic: