jiebi/CodeConvo huggingface dataset:
Change:
use std::path::PathBuf; use std::{env, fs}; <del> use build_helper::git::warn_old_master_branch; </del> use crate::Build; #[cfg(not(feature = "bootstrap-self-test"))] use crate::builder::Builder;

Discussion:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and
Change:
use std::path::PathBuf; use std::{env, fs}; <del> use build_helper::git::warn_old_master_branch; </del> use crate::Build; #[cfg(not(feature = "bootstrap-self-test"))] use crate::builder::Builder;

Discussion:
I am in this state (only 1 modified file): But I just tried to format and got this: Something is quite wrong here. Formatting of only changed files must be correct, otherwise some files in the tree will get spurious formatting changes in PRs. Perhaps is related? I have a vague memory of seeing this misbehavior occasionally in the past though I'm only now remembering to file an issue.
Don't we check formatting of all files in CI anyway?
Most likely. On CI, yes.
Interesting. I swear I've seen spurious formatting changes in PRs. Might be some other effect.
Should be closed by (GH didn't pick up the comment)
Change:
let krate = &self.crates[&krate]; ret.push(krate); for dep in &krate.deps { <ins> if !self.crates.contains_key(dep) { // Ignore non-workspace members. continue; } </ins> // Don't include optional deps if their features are not // enabled. Ideally this would be computed from `cargo // metadata --features …`, but that is somewhat slow. Just

Discussion:
This was triggered by overloading a crate in 's : Causing the following panic:
This happens in . It thinks that the crate is a local crate part of the source tree and then panics when it isn't part of the workspace while trying to get the the path to it.
I'm unable to reproduce this, can you provide more details on exactly what changes were made? Which version of were you pointing to? Which commit of the rust repo are you on? FWIW, modifying a single to point to a local dependency can cause problems and is not the best way to go about using a local copy. Usually you want to specify a in the root .
The same happens for ykrustc when using : It is worked around by having skip that specific crate:
I can't see those links for some reason. GitHub is saying "There isn’t anything to compare. We couldn’t figure out how to compare these references, do they point to valid commits?" For example, the following works for me on latest master ():
Github somehow removed the from the urls. The correct urls are: Try moving to the parent dir. Otherwise it is part of the rust workspace.
I see, I forgot that "path deps are workspace members" does not work if it is outside of the workspace root. Regardless, it is still probably best in this particular case of to use a . BTW, those links still don't seem to work. I just see " This comparison is big! We’re only showing the most recent 250 commits", and a long list of commits. I posted with a fix at .
Seems like github doesn't switch to the "files changed" tab automatically. Anyway here is a copy:
Thanks and for tracking this down. This was just with the latest s of both repos at the time, specifically rust and libc . Maybe I didn't match the versions carefully enough or something, but building the patched out-of-tree with does work correctly. FWIW, I also tried with a , which gave the same error. I can give more details if this changes things.
Change:
"backtrace", "bitflags", "byteorder", <del> "cc", </del> "chalk-engine", "fmt_macros", "graphviz",

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
}; assert_eq!(&obligations, &[]); <ins> // Because of #109628, we may have unexpected placeholders. Ignore them! // FIXME(#109628): panic in this case once the issue is fixed. bounds.retain(|bound| !bound.has_placeholders()); </ins> if !constraints.is_empty() { let span = self.tcx.def_span(body_id);

Discussion:
In that commit, go to folder and run (tested in nightly, stable 1.69 and stable 1.70) : <details<summary<strongBacktrace</strong</summary<p</p</details
This is causing us to leak placeholders into implied bounds. Minimized:
Change:
drop((x0, x1, x2)); assert_eq!(count.get(), 3); } <ins> #[test] fn test_repeat_n_soundness() { let x = std::iter::repeat_n(String::from("use after free"), 0); println!("{x:?}"); pub struct PanicOnClone; impl Clone for PanicOnClone { fn clone(&self) -> Self { unreachable!() } } // `repeat_n` should drop the element immediately if `count` is zero. // `Clone` should then not try to clone the element. let x = std::iter::repeat_n(PanicOnClone, 0); let _ = x.clone(); let mut y = std::iter::repeat_n(Box::new(0), 1); let x = y.next().unwrap(); let _z = y; assert_eq!(0, *x); } </ins>

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:
LL | #[derive(Copy, Clone)] |          ^^^^ unsatisfied trait bound introduced in this `derive` macro = note: the `Copy` trait is required because this value will be copied for each element of the array <del> = help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` </del> = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information = note: this error originates in the derive macro `Copy` (in Nightly builds, run with -Z macro-backtrace for more info) <ins> help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: Foo<String> = Foo(String::new()); LL ~     [ARRAY_REPEAT_VALUE; 4]; | </ins> error: aborting due to previous error

Discussion:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.
Change:
ty::PredicateKind::ConstEvaluatable(a), ty::PredicateKind::ConstEvaluatable(b), ) => tcx.try_unify_abstract_consts((a, b)), <del> (ty::PredicateKind::TypeOutlives(a), ty::PredicateKind::TypeOutlives(b)) => { relator.relate(predicate.rebind(a.0), p.rebind(b.0)).is_ok() </del> <ins> ( ty::PredicateKind::TypeOutlives(ty::OutlivesPredicate(ty_a, lt_a)), ty::PredicateKind::TypeOutlives(ty::OutlivesPredicate(ty_b, lt_b)), ) => { relator.relate(predicate.rebind(ty_a), p.rebind(ty_b)).is_ok() && relator.relate(predicate.rebind(lt_a), p.rebind(lt_b)).is_ok() </ins> } _ => predicate == p, }

Discussion:
Looks like it's possible to for a stricter lifetime than the one used in the type: ... which allows to essentially transmute from to , leading to unsoundness: On my machine, it prints:
oops...
Looks like this regressed in 1.56.0.
introduced this
Re-opening to track beta/stable backport.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
(I'm investigating making a more limited version of this PR for backporting to beta/stable.)
we ended up backporting itself to the 1.57 release. So this is now closed.
Change:
<ins> // check-pass #![feature(inherent_associated_types, generic_const_exprs)] #![allow(incomplete_features)] struct Parent<const O: usize>; impl<const O: usize> Parent<O> { type Mapping<const I: usize> = Store<{ O + I }> where [(); O + I]: ; } struct Store<const N: usize>; impl<const N: usize> Store<N> { const REIFIED: usize = N; fn reify() -> usize { N } } fn main() { let _ = Parent::<2>::Mapping::<{ 12 * 2 }>::REIFIED; let _ = Parent::<1>::Mapping::<{ 2 * 5 }>::reify(); } </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. --I used since just gave a {integer}` error. Don't know if it's related, but thought I should mention it. <!-- 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 --
searched toolchains nightly-2022-11-03 through nightly-2023-03-31 Regression in nightly-2022-11-06 Regression in Regression in
label F-inherentassociatedtypes claim
I've just pushed a commit to that will fix this issue. Thanks for mentioning. That's just an artifact.
Triage: this is no longer ICE since today's nightly. label: +E-needs-test
Change:
"clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "futures", "heck",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
<ins> fn main_ref() { let array = [(); { let mut x = &0; let mut n = 0; while n < 5 { //~^ ERROR constant evaluation is taking a long time x = &0; } 0 }]; let mut ptrs: Vec<*const [u8]> = vec![&array[0..0], &array[0..1], &array, &array[1..]]; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [checkmodprivacy] checking privacy in top-level module [analysis] running analysis passes on this crate --
this bisects to
Change:
let mut context = context; if !place.projection.is_empty() { <del> context = if context.is_mutating_use() { PlaceContext::MutatingUse(MutatingUseContext::Projection) } else { PlaceContext::NonMutatingUse(NonMutatingUseContext::Projection) }; </del> <ins> if context.is_use() { // ^ Only change the context if it is a real use, not a "use" in debuginfo. context = if context.is_mutating_use() { PlaceContext::MutatingUse(MutatingUseContext::Projection) } else { PlaceContext::NonMutatingUse(NonMutatingUseContext::Projection) }; } </ins> } self.visit_local(&place.local, context, location);

Discussion:
MIR may contain debuginfo like this after inlining: Here, the field access is treated like a use of the local in MIR visitors (using ), even though it is not an actual use of . Instead, it should be using .
Can you describe where the change needs to be made? The visit method for debuginfo seems to be correct: It shells out to with , and then shells out through some other methods to . isn't getting the PlaceContext that was called with (I guess because the context of a projection is potentially different than that of the local it's projecting), but it seems to do nothing for field accesses: So what part should I change? Thanks!
Looks like the problem is here:
Okay, thank you!
Change:
CFG_GCCISH_PRE_LIB_FLAGS_arm-linux-androideabi := -Wl,-whole-archive CFG_GCCISH_POST_LIB_FLAGS_arm-linux-androideabi := -Wl,-no-whole-archive CFG_DEF_SUFFIX_arm-linux-androideabi := .android.def <del> CFG_LLC_FLAGS_arm-linux-androideabi := -arm-enable-ehabi -arm-enable-ehabi-descriptors </del> <ins> CFG_LLC_FLAGS_arm-linux-androideabi := </ins> CFG_INSTALL_NAME_arm-linux-androideabi = CFG_LIBUV_LINK_FLAGS_arm-linux-androideabi = CFG_EXE_SUFFIX_arm-linux-androideabi :=

Discussion:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.
Change:
} enum Foo { <ins> //~^ NOTE `Foo` defined here </ins> A(foo::SecretlyEmpty), <ins> //~^ NOTE not covered </ins> B(foo::NotSoSecretlyEmpty), C(NotSoSecretlyEmpty), D(u32, u32),

Discussion:
The following code compiles on nightly (): But if the wrapper type is moved into a module to make the field private, then it does not: (): Making the field makes it compile again. Is this expected? I suppose I could understand if it is; the private fields could change to make actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like . If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an . label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve
label +F-exhaustive_patterns
are we sure this is actually a bug? As I said, I could understand how it's not:
I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics
This is definitely intentional. But yeah, it should have a better error message. Not currently I don't think. It would probably require us to add an trait, eg. something like: This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case. Alternatively, you could give an or method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:
Is supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).
If the type implementing really is uninhabited then there won't actually be any impure code in the match. The call to would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making -only like .

Making a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the in to make it depend on the module.
Change:
<ins> // If we have a long `<code>`, we need to ensure that it'll be fully displayed on mobile, meaning // that it'll be on two lines. emulate: "iPhone 8" // it has the following size: (375, 667) goto: file://|DOC_PATH|/test_docs/long_code_block/index.html // We now check that the block is on two lines: show-text: true // We need to enable text draw to be able to have the "real" size // Little explanations for this test: if the text wasn't displayed on two lines, it would take // around 20px (which is the font size). assert-property: (".docblock p > code", {"offsetHeight": "42"}) </ins>

Discussion:
Otherwise, if too long we can't read them: ! With rule: !
You probs want so that it tries to not wrap mid-word (but still does if it can't do otherwise).
With your suggestion it gives: ! It's weird but in a different way haha.
We can tell the browser where to break words by inserting in the right places. E.g. . Together with some other CSS properties that should give us full control where it'll do the breaking.
it's not clear to me that makes wrapping word-aware (that would be quite a task!) In other words, vs differ only in whether the wrap : Emphasis mine. We don't explicitly use min-content in our CSS as far as I can tell, but looking at the screenshots shared, perhaps it is introduced somewhere by browser intrinsics? Long story short, I think we should use . It produces nicer results in these screenshots, and isn't documented to provide benefits that we care about.
I'm certainly not a CSS expert, I just meant "let's not break idents in the middle" and assumed would be enough for that. It seems like gave the proper answer for breaking correctly around instead of in the middle of the words.