jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass #![feature(generic_associated_types)] #![allow(non_camel_case_types)] trait HasAssoc { type Assoc; } trait Iterate<S: HasAssoc> { type Iter<'a> where Self: 'a; } struct KeySegment_Broken<T> { key: T, } impl<S: HasAssoc> Iterate<S> for KeySegment_Broken<S::Assoc> { type Iter<'a> where Self: 'a, = (); } fn main() {} </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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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. --: I have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that
Change:
// details. pub struct Dependent<T, const X: T>([(); X]); <del> //~^ ERROR the types of const generic parameters must derive `PartialEq` and `Eq` </del> <ins> //~^ ERROR `T` is not guaranteed to `#[derive(PartialEq, Eq)]` </ins> fn main() {}

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.
Change:
self.s.word(" else "); self.print_block(&b) } <ins> hir::ExprKind::Match(ref expr, arms, _) => { // else if let desugared to match assert!(arms.len() == 2, "if let desugars to match with two arms"); self.s.word(" else "); self.s.word("{"); self.cbox(INDENT_UNIT); self.ibox(INDENT_UNIT); self.word_nbsp("match"); self.print_expr_as_cond(&expr); self.s.space(); self.bopen(); for arm in arms { self.print_arm(arm); } self.bclose(expr.span); self.s.word("}"); } </ins> // BLEAH, constraints would be great here _ => { panic!("print_if saw if with weird alternative");

Discussion:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- 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 --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim
Change:
} } Some(ref tr) => { <del> // Any private types in a trait impl fall into two </del> <ins> // Any private types in a trait impl fall into three </ins> // categories. // 1. mentioned in the trait definition // 2. mentioned in the type params/generics <ins> // 3. mentioned in the associated types of the impl </ins> // // Those in 1. can only occur if the trait is in // this crate and will've been warned about on the

Discussion:
AFAIK, you can't put private types in "public" items (public as in marked with ). is not explicitly marked with , but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find ) cc
I agree, I think this may have just been accidentally overlooked when implementing associated types.
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote: Yes, that. There was language in the RFC describing trait item signatures and how they should be treated, and I think we just failed to extend that to associated types. Definitely a bug.
triage: P-backcompat-lang (1.0 beta)
Note also that is still open.
Change:
/// elements. /// /// This sort is unstable (i.e. may reorder equal elements), in-place (i.e. does not allocate), <del> /// and `O(n log n)` worst-case. </del> <ins> /// and `O(m n log m n)` worst-case, where the key function is `O(m)`. </ins> /// /// # Current implementation ///

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<ins> error[E0507]: cannot move out of static item `D` --> $DIR/move-error-snippets.rs:16:18 | LL | | #[macro_use] | |__________________^ move occurs because `D` has type `A`, which does not implement the `Copy` trait ... LL |               aaa!(D); |  __________________^ ... LL |   sss!(); |   ------- in this macro invocation error: aborting due to previous error For more information about this error, try `rustc --explain E0507`. </ins>

Discussion:
When trying to compile the tests for my I get this error: <details<summary</summary</detailsMy understanding is that the compiler was trying to tell me about a borrow checker error; but I have no idea where to start minimizing this error(sorry).
I have managed to get it down to two files: It doesn't work with a in the , it has to be a different file. is then needed to trigger the ICE.
modify labels: I-ICE A-macros C-Bug T-compiler
cc
Seems to be related to 2018 edition? If I use the nightly-2018-10-01 and execute it doesn't ICE, but with it does ICE. well...
Most likely related to the fact that NLL is active in Rust 2018 then.
Bisecting: Somewhere in
Confirmed. gave me the ICE on 2015 as well (forgot that in the good ol' days nll was not a thing) Also confirmed, that edition 2015 does ICE with on and not on (like edition 2018 did above).
Also ICE with
Change:
/// static HTML tree. Each component in the cleaned path will be passed as an /// argument to `f`. The very last component of the path (ie the file name) will /// be passed to `f` if `keep_filename` is true, and ignored otherwise. <del> fn clean_srcpath<F>(src_root: &Path, p: &Path, keep_filename: bool, mut f: F) where </del> <ins> fn clean_srcpath<F>(src_root: &Path, p: &Path, keep_filename: bool, mut f: F) where </ins> F: FnMut(&OsStr), { // make it relative, if possible

Discussion:
After a simple , I tried to generate the crate documentation. I really don't know why I get this error. The problem seems to be here but what's wrong? ^^' The source is on glitch: !/nom- Feel free to ping me if you need to ask me more!
Is this a fluke or is your drive actually full? Is it a regular drive or a network share?
Oops! I didn't see the error message. My fork is stored on Glitch, it's a virtual drive I guess. I must have reached the storage limit authorized by Glitch. edit: ahah, that's it! !
That's not very nice as output... I'll write something a bit better.
As you requested here's the backtrace:
This ICE was changed into a proper error message by . This issue can be closed as a duplicate of .
Ok, thanks! I'll close it!
Change:
|     --      ^^---- |     |       | |     |       expected `{` <del> |     |       help: try placing this code inside a block: `{ 'b: { } }` </del> <ins> |     |       help: try placing this code inside a block: `{ 'b: {} }` </ins> |     this `if` statement has a condition, but no block error: expected `{`, found `'b`

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
} self.structurally_resolved_type(autoderef.span(), autoderef.final_ty(false)); <del> if let Some((did, field_ty)) = private_candidate { </del> <ins> if let Some((adjustments, did, field_ty)) = private_candidate { // (#90483) apply adjustments to avoid ExprUseVisitor from // creating erroneous projection. self.apply_adjustments(base, adjustments); </ins> self.ban_private_field_access(expr, expr_t, field, did); return field_ty; }

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. --: Also checked beta and nightly at : <!-- 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 --
This does not panic on 1.55. Also, it panics on 1.56 regardless of which edition is used. label regression-from-stable-to-stable
searched nightlies: from nightly-2021-07-23 to nightly-2021-11-02 regressed nightly: nightly-2021-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsFrom this rollup, looks relevant, and it landed in 1.56 via backport.
claim
Assigning priority as in the prioritization working group.
Change:
|         | |         function or associated item not found in `👀` |         help: there is an associated function with a similar name: `full_of_✨` <ins> | note: if you're trying to build a new `👀`, consider using `👀::full_of_✨` which returns `👀` --> $DIR/emoji-identifiers.rs:4:5 | LL |     fn full_of_✨() -> 👀 { |     ^^^^^^^^^^^^^^^^^^^^^ </ins> error[E0425]: cannot find function `i_like_to_😄_a_lot` in this scope --> $DIR/emoji-identifiers.rs:13:13

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
.emit(); } Err(CopyImplementationError::HasDestructor) => { <del> span_err!(tcx.sess, span, E0184, </del> <ins> struct_span_err!(tcx.sess, span, E0184, </ins> "the trait `Copy` may not be implemented for this type;  <del> the type has a destructor"); </del> <ins> the type has a destructor") .span_label(span, &format!("Copy not allowed on types with destructors")) .emit(); </ins> } } });

Discussion:
From: src/test/compile- Error E0184 needs a span_label, updating it from: To: Bonus: I'm not sure that note is helping, you can probably just remove it.
On it
- I am releasing this one so someone else can take it, but feel free to come grab another one

From: src/test/compile- Error E0165 needs a span_label, updating it from: To:

From: src/test/compile- Error E0164 needs a span_label, updating it from: To:
Change:
} pub struct uv_stat_t { <del> priv st_dev: libc::uint64_t, </del> <ins> st_dev: libc::uint64_t, </ins> st_mode: libc::uint64_t, priv st_nlink: libc::uint64_t, priv st_uid: libc::uint64_t, priv st_gid: libc::uint64_t, priv st_rdev: libc::uint64_t, <del> priv st_ino: libc::uint64_t, </del> <ins> st_ino: libc::uint64_t, </ins> st_size: libc::uint64_t, priv st_blksize: libc::uint64_t, priv st_blocks: libc::uint64_t,

Discussion:
This should instead use the interface which does not block the thread. Additionally, this should remove the functions in the file along with related definitions. This is a pretty good first project for anyone wanting to sink their teeth into some library work! It's a bit of refactoring and should result in a nice large negative diffstat!
What about calls to in ?
It seems that there is no 1-to-1 mapping of to . Particularly, the latter is missing fields, such as , and OS-specific attributes, such as on MacOS and FreeBSD. I suppose that will have to have those fields to it.
The function should not exist in that current form, and it's fine to drop fields for now. A rust should work the same on all platforms, not create different structs with different fields (very easy to miscompile on other platforms).
When I changed the implementation of in to call and then , I hit a compiler error: I do have an , but nothing extra seems to be printed. Should I file a separate issue for this?
The calls to will raise on the condition when they encounter an error. In this case it looks like the error was that a file was not found. The return value of will be , but you'll need to explicitly catch the error as well for now (and ignore it or continue to propagate it).
If it is fine to drop fields for now, I suppose we should remove tests that reference such fields. E.g. in we have for two tests: and
Both the fields in question exist in , I suppose I will just add them to then in that case.
Feel free to modify as much as you need, especially if there's information inside of on all platforms, then feel free to add it in!
Change:
.collect::<Vec<(usize, String)>>(); for ((span, empty_where), obligations) in type_params.into_iter() { restrict_type_params = true; <ins> // #74886: Sort here so that the output is always the same. let mut obligations = obligations.into_iter().collect::<Vec<_>>(); obligations.sort(); </ins> err.span_suggestion_verbose( span, &format!(

Discussion:
version 1.44.1 I will be adding an feature as part of , just wanted to confirm these failures are OK to ignore: ~ ~ CC and who wrote the tests, but I guess you may not be responsible for the underlying behavior.
We have adjusted the const test to be endianess-independent in
For the suggestion in we can presort the restrictions so that the output is always consistent.
Change:
/// Link some files into a rustc sysroot. /// <del> /// For a particular stage this will link all of the contents of `out_dir` /// into the sysroot of the `host` compiler, assuming the artifacts are /// compiled for the specified `target`. fn add_to_sysroot(out_dir: &Path, sysroot_dst: &Path) { // Collect the set of all files in the dependencies directory, keyed // off the name of the library. We assume everything is of the form // `foo-<hash>.{rlib,so,...}`, and there could be multiple different // `<hash>` values for the same name (of old builds). let mut map = HashMap::new(); for file in t!(fs::read_dir(out_dir.join("deps"))).map(|f| t!(f)) { let filename = file.file_name().into_string().unwrap(); // We're only interested in linking rlibs + dylibs, other things like // unit tests don't get linked in if !filename.ends_with(".rlib") && !filename.ends_with(".lib") && !is_dylib(&filename) { </del> <ins> /// For a particular stage this will link the file listed in `stamp` into the /// `sysroot_dst` provided. fn add_to_sysroot(sysroot_dst: &Path, stamp: &Path) { t!(fs::create_dir_all(&sysroot_dst)); let mut contents = Vec::new(); t!(t!(File::open(stamp)).read_to_end(&mut contents)); for part in contents.split(|b| *b == 0) { if part.is_empty() { </ins> continue } <del> let file = file.path(); let dash = filename.find("-").unwrap(); let key = (filename[..dash].to_string(), file.extension().unwrap().to_owned()); map.entry(key).or_insert(Vec::new()) .push(file.clone()); } // For all hash values found, pick the most recent one to move into the // sysroot, that should be the one we just built. for (_, paths) in map { let (_, path) = paths.iter().map(|path| { (mtime(&path).seconds(), path) }).max().unwrap(); </del> <ins> let path = Path::new(t!(str::from_utf8(part))); </ins> copy(&path, &sysroot_dst.join(path.file_name().unwrap())); } }

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:
"[rust]", ) }), <ins> unstable("html-no-source", |o| { o.optflag("", "html-no-source", "Disable HTML source code pages generation") }), </ins> ] }

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
<ins> error[E0277]: the size for values of type `(dyn Foo + 'static)` cannot be known at compilation time --> $DIR/issue-111932.rs:4:20 | LL |     foos.for_each(|foo| { |                    ^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `(dyn Foo + 'static)` = note: all function arguments must have a statically known size = help: unsized fn params are gated as an unstable feature error[E0277]: the size for values of type `dyn Foo` cannot be known at compilation time --> $DIR/issue-111932.rs:5:26 | LL |         println!("{:?}", foo); |                   ----   ^^^ doesn't have a size known at compile-time |                   | |                   required by a bound introduced by this call | = help: the trait `Sized` is not implemented for `dyn Foo` note: required by a bound in `core::fmt::rt::Argument::<'a>::new_debug` --> $SRC_DIR/core/src/fmt/rt.rs:LL:COL = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Notice how the last 2 suggestions aren't valid in such a closure: The suggestions given in should help me get closer to fixing the error, or at least not have invalid syntax. No response No response Output of :
(if is used in the snippet, comes up again with leaking implementation details)
Change:
<del> Subproject commit c3eb3c7608f439231d0c1340af6b720f113b4bf4 </del> <ins> Subproject commit eee68eafa7e8e4ce996b49f5551636639a6c331a </ins>

Discussion:
rustup reports of 0.6.1 crashes: These were built with rustup 0.6.0 crashed on OS X 10.10+. Fixed with a strategic That was built with Reducing these has been very difficult and I have nothing for them right now. cc
Do you know of a nightly which doesn't result in crashes?
looking for one now.
rust- looks like the exact same issue AFAICT.
from 2016-08-18 is the first nightly that miscompiles. Curiously this is also the first 1.13 nightly. Unfortunately the bug is on beta too. reproducing: commit nightly results: 2016-08-10, rustc 1.12.0-nightly ( 2016-08-09) - good 2016-08-16, rustc 1.12.0-nightly ( 2016-08-15) - build error 2016-08-17, rustc 1.12.0-nightly ( 2016-08-16) - build error 2016-08-18, rustc 1.13.0-nightly ( 2016-08-17) - bad 2016-08-22, rustc 1.13.0-nightly ( 2016-08-21) - bad 2016-08-26, rustc 1.13.0-nightly ( 2016-08-25) - bad stable/beta results: rustc 1.11.0 ( 2016-08-15) - good rustc 1.12.0-beta.2 ( 2016-08-24) - bad! beta-2016-08-16, rustc 1.12.0-beta.1 ( 2016-08-16) - buld error
Removing the from appears to make the crash go away.
I am trying to minimize a test case next.
Reduced case. This segfaults on x86_64-unknown-linux-gnu with , compiled with .
Normalized to: Backtrace is: Note the passed to .
So far I've found that the drop glue for optimizes to start with: That is reading the data pointer of the (which may be null in the case, where it represents ) and assuming it's .

While the null check which distinguishes between and is still there, it gets optimized out later, due to that metadata on the first . EDIT: Those 3 instructions are for the case, however, the IR ends up looking like: The has turned into a (presumably "everything but "). Which is still fine, is taken for and for , so you would think_ it'd work. But SimplifyCFG comes in and shoves the load into the entry block: What does this mean? LLVM has a nasty (class of) bug around metadata hints, not updating/removing them when needed MIR trans and the lifetime intrinsics are coincidental factors, causing the crash, not the misoptimization the assembly is pretty similar without lifetime intrinsics, the null check is still missing
Barebones reproduction:
Found a LLVM commit should've fixed this (but apparently didn't fully?): EDIT: Most likely  also needs that metadata-stripping treatment.
Filed LLVM bug report:
But I thought that bad-metadata loads only result in , not in UB. That's how the last of these bugs were fixed.
Just is useless, the metadata is there to kill later redundant checks. Hopefully the fix is just to add one or two of those metadata stripping loops to that unhandled case.
Fix is Recommend backport to beta, too.
Thanks a bunch
LLVM patch was merged to 3.9 stable branch in and will be included in 3.9.1 release.