jiebi/CodeConvo huggingface dataset:
Change:
<del> Subproject commit 0903c72cbbc3dafcb5c88820e4a8a98c3a764cf3 </del> <ins> Subproject commit 6ceaaa4b0176a200e4bbd347d6a991ab6c776ede </ins>

Discussion:
E.g.: (and this results in a 8MB file, etc). Note that this works:
Looking at LLVM IR: It looks like that the padding is troublesome.
So I'm not sure what to do here. This is clearly also an LLVM issue, but with LLVM being supported down to 3.7, fixing just LLVM doesn't seem enough.
If it's indeed an LLVM bug, fixing LLVM and cherry-picking the patch into may be the best we can do. This is often the case with LLVM issues, even with blatant miscompiles (e.g., ).
I tagged this as in a sense that it generates an executable that is suboptimal (i.e. what is the spirit of the tag).
Relevant thread on llvm-dev: (well, not a thread just yet)
Still reproduces on 1.20 and (). Did the patch ever happen?
I have a . It's been accepted, so now it just needs to be merged and then we should be able to cherry-pick it.
This has now been merged in. Should be ready for cherry-picking!
Yay! Thanks If someone wants to drive this to the finish line the backporting process looks like this: Fork rust-lang/llvm. Make a new branch -- base it off the branch. Cherry pick the changes (). Send a PR to rust-lang/llvm (target branch is ).Once that PR is merged, fork rust-lang/rust. Make a new branch -- base it off the master branch. Update the src/llvm submodule to point to the new HEAD of the branch. Send a PR with the updated submodule to rust-lang/rust (target branch is master).Cross your fingers and hope that bors likes the changes :slightlysmilingface: Feel free to cc me on those PRs. I can only r+ the rust-lang/rust PR, though.
thanks for laying out the steps! I always meant to follow up here, but never got around to it (and wasn't sure what the process was on the rust/llvm end). I've followed the first steps: hopefully we can soon get this fix in for good! :)
Change:
let codegen_options = CodegenOptions::build(early_dcx, matches); let unstable_opts = UnstableOptions::build(early_dcx, matches); <ins> let force_unstable_if_unmarked = unstable_opts.force_unstable_if_unmarked; </ins> let dcx = new_dcx(error_format, None, diagnostic_width, &unstable_opts);

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
<del> error[E0119]: conflicting implementations of trait `Copy` for type `S<_>` --> $DIR/bad-const-wf-doesnt-specialize.rs:9:1 </del> <ins> error: the constant `N` is not of type `usize` --> $DIR/bad-const-wf-doesnt-specialize.rs:8:29 </ins> | LL | impl<const N: i32> Copy for S<N> {} <del> | -------------------------------- first implementation here LL | impl<const M: usize> Copy for S<M> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `S<_>` </del> <ins> |                             ^^^^ | note: required by a bound in `S` --> $DIR/bad-const-wf-doesnt-specialize.rs:6:10 | LL | struct S<const L: usize>; |          ^^^^^^^^^^^^^^ required by this bound in `S` </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0119`. </del>

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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
let len = other.len(); let cap = other.cap(); <del> if other.head != 0 { </del> <ins> if other.tail != 0 { </ins> ptr::copy(buf.add(other.tail), buf, len); } Vec::from_raw_parts(buf, len, cap)

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 my first bug report, so please correct me s if I miss anything :-) I use VecDeque<u8in a toy application () which is handling external reads in a loop, and does possible partial handling of the input. My pattern is I call reserve(N) before pushback() N times, then makecontiguous(), then doing some popfront(). I noticed the app was behaving badly, and was able to generate a stand-alone test case which shows the bug. The code is pretty boring and repetitive, so I put it at to avoid spamming here. Just issue "cargo run" after cloning out that code, and look for the word "BUG" within the terminal output: According to the docs, popfront() on an empty VecDeque should return None. Instead, this happens: If I set the boolean "doreserve" to be false, thus getting rid of all the reserve() calls, I get the expected behavior: The same happens if I set "domake_contiguous" to false as well - so calling both functions is a prerequisite to trigger the bug. The same thing happens in debug and release builds. <!-- 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. --The below is the version I found it in, but thanks a lot to Steve Klabnik for also testing it on nightly and getting the same buggy behavior. :
I created a minimal sample:
Hmm, if it double-frees then why does Miri not catch it?
Assigning and removing as in the prioritization working group.
Some time ago I've read somewhere that Rust stdlib VecDeque is cursed. I didn't believe them. I'm changing opinion... -.-
This specific case doesn't double free (i32::drop is a noop), using a might have been a better example...
Still, this is memory-unsafe, right?
Yes, It's still a use-after-free regardless
claim
Based on my conversation with lcnr, jonas-schievink, and others , it seems that using with copy types is not UB (it still exhibits a bug though!) because copy types aren't freed. It is UB with non-copy types though (e.g. ).
Change:
} cargo.arg("--manifest-path") .arg(build.src.join("src/libtest/Cargo.toml")); <del> build.run(&mut cargo); update_mtime(build, &libtest_stamp(build, compiler, target)); </del> <ins> run_cargo(build, &mut cargo, &libtest_stamp(build, compiler, target)); </ins> } /// Same as `std_link`, only for libtest

Discussion:
Rustbuild compiles the compiler in a particular location and is then responsible for copying artifacts over to the actual structure the compiler is expecting (e.g. rustbuild assembles a sysroot). In order to handle stale folders rustbuild , deduplicated by hash. This pretty obviously, though, doesn't work with multiple versions of the same library! We should probably call Cargo with and learn about compiled artifacts, that way we can copy precisely what we need to into the sysroot.
Change:
let bounding_span = Span::with_root_ctxt(lo, hi); // The different spans might belong to different contexts, if so ignore suggestion. let lines = sm.span_to_lines(bounding_span).ok()?; <del> assert!(!lines.lines.is_empty()); </del> <ins> assert!(!lines.lines.is_empty() || bounding_span.is_dummy()); </ins> // We can't splice anything if the source is unavailable. if !sm.ensure_source_file_source_present(lines.file.clone()) {

Discussion:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.
Change:
packages: &["selectors"], features: None, manifest_path: None, <ins> filters: &[], </ins> }, Test { name: "diesel",

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
<ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage
Change:
} impl<T:Copy> Cell<T> { <del> /// Creates a new `Cell` containing the given value. /// /// # Examples /// /// ``` /// use std::cell::Cell; /// /// let c = Cell::new(5); /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[inline] pub const fn new(value: T) -> Cell<T> { Cell { value: UnsafeCell::new(value), } } </del> /// Returns a copy of the contained value. /// /// # Examples

Discussion:
broke a library of mine where I had code like this: calls that used to call this trait method now call the new inherent method, but since that’s unstable the crate didn’t build until I . After that I could remove the trait since the new method has the same behavior. Anyway, this is just FYI. If we don’t want this kind of breakage we can’t add any new method to existing types ever, so that doesn’t sound viable. If the new method had had different behavior or if I wanted to keep supporting older compilers, it wouldn’t be too hard to rename my trait’s method or use UFCS.
Yeah in general we reserve the right to break downstream code with differences in method resolution because the downstream code can always be written in an "elaborated" form which works on all compilers (e.g. using ufcs). If a change to the standard library breaks an excessive amount of code in the ecosystem, though, then we'd need to take the steps much more purposefully.
Sounds good. Again, I don’t expect anything to change here and only made the previous comment to let people know this happened. I made this particular crate as an experiment, I don’t know of anyone actually using it.
Given that the core changes to the bounds on existing methods were instantly stable, it doesn't make a lot of sense to keep and as unstable. I propose we immediately stabilize these APIs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
ping (checkbox)
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
What’s the next step here? Batch stabilization PR near the end of the release cycle?
Yep, I'm preparing one right now.
Change:
<ins> trait Iterable { type Item; fn iter(&self) -> impl Sized; } // `ty::Error` in a trait ref will silence any missing item errors, but will also // prevent the `associated_items` query from being called before def ids are frozen. impl Iterable for Missing { //~^ ERROR cannot find type `Missing` in this scope fn iter(&self) -> Self::Item {} } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'still mutable'', 'thread 'rustc' panicked at 'still mutable'' File: --auto-reduced (treereduce-rust): original: Version 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: [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [opaquetypesdefinedby] computing the opaque types defined by [typeck] type-checking [analysis] running analysis passes on this crate --
cc , also see for a similar regression fixed by nn
Not sure that was actually fixed. The PR seems entirely unrelated
on a nighty before , this errored with
Oh I think I see how that got "fixed". It bailed out of compilation early enough not to hit the ICE anymore by emitting stashed errors earlier. So it got hidden again, and now it's back againbecause of some subtle change in query ordering. We probably need to run this query explicitly for all traits and impls before the big def id freeze.
Change:
// Convert the bounds into obligations. let impl_obligations = traits::predicates_for_generics( <del> |_idx, span| { let misc = traits::ObligationCause::misc(span, self.body_id); let parent_trait_pred = ty::Binder::dummy(ty::TraitPredicate { trait_ref: ty::TraitRef::from_method(self.tcx, impl_def_id, substs), constness: ty::BoundConstness::NotConst, polarity: ty::ImplPolarity::Positive, }); misc.derived_cause(parent_trait_pred, |derived| { traits::ImplDerivedObligation(Box::new( traits::ImplDerivedObligationCause { derived, impl_or_alias_def_id: impl_def_id, impl_def_predicate_index: None, span, }, )) }) </del> <ins> |idx, span| { let code = if span.is_dummy() { traits::ExprItemObligation(impl_def_id, self.scope_expr_id, idx) } else { traits::ExprBindingObligation( impl_def_id, span, self.scope_expr_id, idx, ) }; ObligationCause::new(self.span, self.body_id, code) </ins> }, self.param_env, impl_bounds,

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 --
Minimized via  and some manual item deletion: I can take a quick look into this one I guess. claim
Change:
} } }); <ins> // Skip run-make tests as revisions are not supported. if entry.path().strip_prefix(tests_path).is_ok_and(|rest| rest.starts_with("run-make")) { return; } </ins> for (rev, RevisionInfo { target_arch, llvm_components }) in &header_map { let rev = rev.unwrap_or("[unspecified]"); match (target_arch, llvm_components) {

Discussion:
Tests doing codegen for specific targets need directives. These are the tests that are currently missing the directives and failing if LLVM is built without various aarch64/arm/thumb components or wasm. [ ] testsrun-makeprint-target-list [ ] testsrun-makeprint-to-output [ ] testsrun-makeprint-cfg [ ] testsrun-maketarget-without-atomic-cas Originally posted by in
E.g. for this looks a bit awkward, maybe we can dump , where is shamelessly stolen from tidy: Between this directive and , it is not exactly very clear what's happening.

In noticed was failing for (and other experimental llvm components) on the CI builder with (specifically ) it was already noticed that seemed to fail for . Is this expected? Or what is the expected test behavior when is ran (on the CI builder)? Or is it expected that we should skip trying to run this check for the and other experimental llvm component targets? Update: this is also true for experimental llvm components , , and , not too sure what the correct behavior is. Currently these targets are skipped by 's check.
Is there any COMPILETESTNEEDSALLLLVMCOMPONENTS set by us for this jobs?. It seems like the same issue. I will check it later.
Well, I'm not familiar with rmake. However, the right logic should be like: If is not set and do not have the , then we could skip it. is set at , and it is only used at now.
Ah thank you, that sounds about right.
Change:
paths: Vec<PathBuf>, }, Check { <del> // Whether to run checking over all targets (e.g., unit / integration // tests). all_targets: bool, </del> paths: Vec<PathBuf>, }, Clippy {

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
<ins> // Checks to ensure that we properly detect when a closure constrains an existential type #![feature(existential_type)] use std::fmt::Debug; fn main() { existential type Existential: Debug; fn _unused() -> Existential { String::new() } //~^ ERROR: concrete type differs from previous defining existential type use let null = || -> Existential { 0 }; println!("{:?}", null()); } </ins>

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
<ins> error[E0658]: `cfg(overflow_checks)` is experimental and subject to change --> $DIR/feature-gate-cfg_overflow_checks.rs:3:7 | LL | #[cfg(overflow_checks)] |       ^^^^^^^^^^^^^^^ | = note: see issue #111466 <https://github.com/rust-lang/rust/issues/111466> for more information = help: add `#![feature(cfg_overflow_checks)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
An enhancement request discussed here: (That thread also contains a hacky solution by Yandros). I propose to add a config like this: #[cfg(overflow_checks)] I would like to use it to enable/disable lines of code that perform safe unsafe "as" casts replacing them with casts when I compile with debug builds or with release builds compiled with "-C overflow-checks".
modify labels: C-enhancement
label A-attributes T-compiler
I’d also be interested in this.
Tracking issue: