jiebi/CodeConvo huggingface dataset:
Change:
), UnresolvedTy(_) => write!(f, "unconstrained type"), UnresolvedConst(_) => write!(f, "unconstrained const value"), <ins> UnresolvedEffect(_) => write!(f, "unconstrained effect value"), </ins> } } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: is not fully resolved', 'error: internal compiler error: is not fully resolved' File: --Another regression of snippet: 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: [checkmodimpl_wf] checking that impls are well-formed in top-level module [analysis] running analysis passes on this crate --
This is caused by the fact that  does not check for const effect vars when visiting . It should be relatively simple to match on in the folder.
Working on this one.
Change:
let initialized = slice::from_raw_parts_mut(ptr, self.len); let spare = slice::from_raw_parts_mut(spare_ptr, spare_len); <del> (initialized, spare) </del> <ins> (initialized, spare, &mut self.len) </ins> } } }

Discussion:
Looking here, the internal length of the vector is only adjusted at the end of the loop This has the caveat that if cloning panics, the Vec will start to unwind and only drop the first elements which doesn't include the most recently appended ones. Something more in line with how the stdlib does things might look like this: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is not unsafe, leaking items is safe:
Sure; never said it was unsafe. This is more about making sure programs who gracefully handle panics don't wind up eventually exhausting resources.
Assigning as part of the .
I would like to fix this claim
The fix seems pretty straight-forward. The Clone specialization just needs a RAII type that handles adjusting the Vec's new len in its Drop implementation, as I've linked in my MiniVec. Copy can't fail so there's no need to adjust that specialization. The only thing that could theoretically panic in that case would be reallocating and in that case, there's no need to worry about the len.
Change:
let mut param_found = FxHashMap::default(); if self.can_eq(self.param_env, ty, found).is_ok() { // We only point at the first place where the found type was inferred. <del> for (i, param_ty) in sig.inputs().skip_binder().iter().skip(1).enumerate() { </del> <ins> for (param_ty, arg) in param_tys.zip(args) { </ins> if def_self_ty.contains(*param_ty) && let ty::Param(_) = param_ty.kind() { // We found an argument that references a type parameter in `Self`, // so we assume that this is the argument that caused the found // type, which we know already because of `can_eq` above was first // inferred in this method call. <del> let arg = &args[i]; </del> let arg_ty = self.node_ty(arg.hir_id); if !arg.span.overlaps(mismatch_span) { err.span_label(

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. --Ran into an ICE while refactoring. Only happens on nightly. Don't know what else I should write here. <!-- 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 --
I cannot reproduce this using on . I ran it on Could you try bisecting this yourself locally (I am not able to right now)
I hit this same bug and got a patch, can post a PR soon if useful!
Sounds great! assign
Change:
<ins> #![feature(non_lifetime_binders)] //~^ WARNING the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes pub fn bar() where for<const N: usize = { (||1usize)() }> V: IntoIterator //~^ ERROR cannot find type `V` in this scope [E0412] { } fn main() { bar(); } </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
Change:
diag.span_suggestion( span, *msg, <del> format!("{}.as_ref()", snippet), </del> <ins> // HACK: fix issue# 100605, suggesting convert from &Option<T> to Option<&T>, remove the extra `&` format!("{}.as_ref()", snippet.trim_start_matches('&')), </ins> Applicability::MachineApplicable, ); }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: The error is correct, but I think the diagnostic is wrong. The second recommendation to call is sound, but the first one () seems like bad advice. This reproduces on 1.61 (on my workstation), as well as 1.63 (stable channel in playground), 1.64 (beta channel in playground), and 1.65 (nightly channel in playground). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Intresting.. This code also make wrong help, The current output is: Using is a bad advice.
claim
Change:
<ins> //@ check-pass fn higher_ranked_fndef(ctx: &mut ()) {} fn test(higher_ranked_fnptr: fn(&mut ())) { fn as_unsafe<T>(_: unsafe fn(T)) {} // Make sure that we can cast higher-ranked fn items and pointers to // a non-higher-ranked target. as_unsafe(higher_ranked_fndef); as_unsafe(higher_ranked_fnptr); } fn main() {} </ins>

Discussion:
I tried this code: I expected to see it work. Instead, this happened: This regressed in This only happens when coercing from safe to unsafe, not unsafe to unsafe or safe to safe. I probably forgot something about how we construct the adjustment from unsafe to safe fn.
Change:
(expr::cast_integral, expr::cast_pointer) => { llvm::LLVMConstIntToPtr(v, llty.to_ref()) } <ins> (expr::cast_pointer, expr::cast_integral) => { llvm::LLVMConstPtrToInt(v, llty.to_ref()) } </ins> _ => { cx.sess().impossible_case(e.span, "bad combination of types for cast")

Discussion:
The following program causes rustc to crash: Obviously it's badly typed (converting void to a pointer type), but the compiler shouldn't crash here right? :) output of rustc -v: rustc 0.12.0-pre-nightly ( 2014-09-11 00:05:41 +0000) backtrace from trying to compile; Let me know if you need more information.
Yes, any ICE is bad. Thanks!
Simpler: Works with every C-like enum.
I'll try to fix this one together with
Fixed in
Change:
} else { unsafe { self.len -= 1; <ins> core::intrinsics::assume(self.len < self.capacity()); </ins> Some(ptr::read(self.as_ptr().add(self.len()))) } }

Discussion:
The following code should be optimized to a no-op afaict, but instead gives: (this is true on stable, beta and nightly). I think a blocking point here is that rustc/LLVM do not manage to infer the invariant: Note that the version with asserts for this invariant removes the useless conditional call to but instead gets useless calls to assert failure code.
I think there are two issues here: the invariant isn't encoded anywhere inside the push and pop methods llvm's constraint elimination pass (in llvm 16) isn't smart enough to figure these things out (even with the s) The first issue can be fixed by adding s to push and pop. The second one is somewhat tricky, however we are fortunate that this has been improved somewhat already in upstream llvm: (c++ reproducer, so it's not directly visible that the constraint elimination pass got improved) (llvm-ir)
Thanks for investigating! Unfortunately your code is equivalent to this Rust code which gets correctly optimized (): I'm not proficient in C++ but I'll try to find an example closer to Rust.
This gets correctly optimized, I'll try a PR to add the assume to and see how it does on benchmarks.
Just ran into which seems similar
Also
Change:
// happening. return Ok(self.const_eval(GlobalId { instance, promoted }, val.ty)?); } <del> ty::ConstKind::Infer(..) | ty::ConstKind::Bound(..) | ty::ConstKind::Placeholder(..) => { </del> <ins> ty::ConstKind::Infer(..) | ty::ConstKind::Placeholder(..) => { </ins> span_bug!(self.cur_span(), "const_to_op: Unexpected ConstKind {:?}", val) } ty::ConstKind::Value(val_val) => val_val,

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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 --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
/// let s = "hello".to_string(); /// is_hello(s); /// ``` <ins> /// /// # Generic Impls /// /// - `AsRef` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsRef<T: ?Sized> { /// Performs the conversion.

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
let impl_items = self.create_impl_from_item(item); for associated_trait in associated_traits.iter() { <del> let trait_ref = ty::node_id_to_trait_ref( self.crate_context.tcx, associated_trait.ref_id); </del> <ins> let trait_ref = ty::node_id_to_trait_ref(self.crate_context.tcx, associated_trait.ref_id); </ins> debug!("(checking implementation) adding impl for trait '{}', item '{}'", trait_ref.repr(self.crate_context.tcx), token::get_ident(item.ident));

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
self.constraint_sccs.as_ref() } <del> /// Returns whether the given SCC has any member constraints. pub(crate) fn scc_has_member_constraints(&self, scc: ConstraintSccIndex) -> bool { self.member_constraints.indices(scc).next().is_some() } </del> /// Returns whether the given SCC is live at all points: whether the representative is a /// placeholder or a free region. pub(crate) fn scc_is_live_at_all_points(&self, scc: ConstraintSccIndex) -> bool {

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
cfg.flag("-fomit-frame-pointer"); cfg.flag("-ffreestanding"); cfg.define("VISIBILITY_HIDDEN", None); <del> cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); </del> <ins> if !target.contains("windows") { cfg.define("COMPILER_RT_HAS_UNAME", Some("1")); } else { profile_sources.push("WindowsMMap.c"); } </ins> } // Assume that the Unixes we are building this for have fnctl() available

Discussion:
I am trying to see if -Z pgo-gen is available on Windows-Gnu: I am using: I am using a very small Rust test program: If I compile with: rustc -Z pgo-gen It gives me: error: debugging option requires a string (Z pgo-gen=<value) If I compile with (using a random string?): rustc -Z pgo-gen=abc It gives me: error[E0463]: can't find crate for
Hi, I was also struggling with that! :) The is supposed to be the profile file which details are written into after executing the pgo-gen instrumented binary and details are read from when building the binary for the second time with pgo-use. So  might work :)
I've tried to do as you say, but perhaps I am doing something wrong. I've created a binary project with cargo (just the hello world), then I've set the variable: Then I've compiled: It gives me:
Hm, I'm not sure what is going on there now (I also can't reproduce since not a windows user), sorry :/
Using: Calling rustc directly gives:
GNU toolchain is built without profiler:
I wonder if we could just enable the profiler on .
I think I can find time this week to test it. I'm almost sure PGO was broken on some older GCC version but I cannot recall the details.
Status update: I've got it working few days ago but pushing this upstream is blocked on upgrading to 0.1.15. It was meant to be done by but was backed off.
Change:
call_locations, no_emit_shared: false, html_no_source, <ins> force_unstable_if_unmarked, </ins> }; Some((options, render_options)) }

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:
LLVM_TARGET="--target=$t" # Disable unused LLVM features <del> LLVM_OPTS="$LLVM_DBG_OPTS --disable-docs  --enable-bindings=none --disable-threads  --disable-pthreads" </del> <ins> LLVM_OPTS="$LLVM_DBG_OPTS --disable-docs --enable-bindings=none" </ins> case "$CFG_C_COMPILER" in ("ccache clang")

Discussion:
After and , rustc is ready to use LLVM completely threadsafely. All that's missing is to the and flags to LLVM's configure script. Once this is done, the should be uncommented as well. This is a simple change, but requires the bots to rebuild LLVM (which has caused problems in the past). has some other LLVM patches to integrate, and this would fit nicely with those.
and are closed now, so this should be ready to be closed as well. I'm not sure what the problems are with the bots rebuilding LLVM ( so I'm a bit hesitant to try it myself. I'd like this to be fixed so I can re-enable the rustpkg tests, though.
I just opened a pull request () to actually stop passing this option to configuring LLVM. The problem is that this doesn't trigger an LLVM rebuild, so once the change has gone through the bots need to have their llvm checkout cleaned before landing the further improvements (uncommenting that block of code to enable a threadsafe rustc)
We can try running the bots with after that patch lands, but I don't know if it works. Without graydon I think we can at least manually clean the windows, mac, and bsd bots.