jiebi/CodeConvo huggingface dataset:
Change:
<del> error[E0284]: type annotations needed: cannot satisfy `the constant `use_dyn::<{_: usize}>::{constant#0}` can be evaluated` --> $DIR/object-safety-ok-infer-err.rs:20:5 </del> <ins> error[E0284]: type annotations needed --> $DIR/object-safety-ok-infer-err.rs:19:5 </ins> | LL |     use_dyn(&()); <del> |     ^^^^^^^ cannot satisfy `the constant `use_dyn::<{_: usize}>::{constant#0}` can be evaluated` </del> <ins> |     ^^^^^^^ cannot infer the value of the const parameter `N` declared on the function `use_dyn` </ins> | note: required by a bound in `use_dyn` --> $DIR/object-safety-ok-infer-err.rs:14:55 | LL | fn use_dyn<const N: usize>(v: &dyn Foo<N>) where [u8; N + 1]: Sized { |                                                       ^^^^^ required by this bound in `use_dyn` <ins> help: consider specifying the generic argument | LL |     use_dyn::<N>(&()); |            +++++ </ins> error: aborting due to previous error

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. --Based on the example in , which after the changes in would output an error. The following code, however, does not output such an error, although I believe it should. Given the following code: <!-- Please provide a link to --The current output is: This only happens if the is included. This also compiles if you don't include the call of in main. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
dont think this is related to adtconstparams as this has the same error:
the reason this happens is because from we don't infer the value for . The error message should be improved by using in this branch for that the predicates should be searched for a relevant inference variable.
going to mentor this issue in case someone wants to fix this
claim
Change:
} #[test] <ins> fn make_contiguous_head_to_end() { let mut dq = VecDeque::with_capacity(3); dq.push_front('B'); dq.push_front('A'); dq.push_back('C'); dq.make_contiguous(); let expected_tail = 0; let expected_head = 3; assert_eq!(expected_tail, dq.tail); assert_eq!(expected_head, dq.head); assert_eq!((&['A', 'B', 'C'] as &[_], &[] as &[_]), dq.as_slices()); } #[test] </ins> fn test_remove() { // This test checks that every single combination of tail position, length, and // removal position is tested. Capacity 15 should be large enough to cover every case.

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:
return did; } inline::record_extern_fqn(cx, did, kind); <del> if let ItemType::Trait = kind { inline::record_extern_trait(cx, did); } </del> did }

Discussion:
Run on this and get an ICE. Note that documenting itself does not panic, and that the is necessary. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also reproduces on Linux (GitHub Actions) with the same nightly version. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc -T-compiler
It looks like this started after commit . () I was able to create a MCVE: <details<summaryBacktrace:</summary</details
cc
Further minimized: The issue disappears if the private is removed. Looks like some logic in rustdoc is over-eager to pull in stuff through private imports, links in 's methods are not visible in the generated documentation and shouldn't be resolved at all.
--are responsible for including the trait into the rustdoc's crate representation, still unclear why.
Fixed in
Change:
<ins> error: cannot use value of type `!` for inline assembly --> $DIR/issue-87802.rs:9:36 | LL |         asm!("/* {0} */", out(reg) x); |                                    ^ | = note: only integers, floats, SIMD vectors, pointers and function pointers can be used as arguments for inline assembly error: aborting due to previous error </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 --
Somewhere during compilation of this code, LLVM's ). Because of that, rustccodegenllvm::asm::inlineasmcall , and the parent function then .
I a statement to log the function type and constraints string passed to LLVM:
claim
Change:
<ins> // run-rustfix #![allow(dead_code)] struct A { b: B, } enum B { Fst, Snd, } union Foo { bar: u32, qux: f32, } fn main() { let a = A { b: B::Fst }; if let B::Fst = a.b {}; //~ ERROR mismatched types [E0308] //~^ HELP you might have meant to use field `b` of type `B` match a.b { //~^ HELP you might have meant to use field `b` of type `B` //~| HELP you might have meant to use field `b` of type `B` B::Fst => (), //~ ERROR mismatched types [E0308] B::Snd => (), //~ ERROR mismatched types [E0308] } let foo = Foo { bar: 42 }; match unsafe { foo.bar } { //~^ HELP you might have meant to use field `bar` of type `u32` 1u32 => (), //~ ERROR mismatched types [E0308] _ => (), } } </ins>

Discussion:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
// that type, and when we finish expanding that type we remove the // its DefId. seen_opaque_tys: FxHashSet<DefId>, <ins> // Cache of all expansions we've seen so far. This is a critical // optimization for some large types produced by async fn trees. expanded_cache: FxHashMap<(DefId, SubstsRef<'tcx>), Ty<'tcx>>, </ins> primary_def_id: DefId, found_recursion: bool, tcx: TyCtxt<'tcx>,

Discussion:
There is a crate inside of Fuchsia whose compile times increased from ~500ms to ~120s in the last month of Rust compiler updates. It hasn't been easy so far to provide a minimal example, but I will keep working at it. Some bisecting revealed that it actually consisted of two performance regressions, both affecting the time spent in : The first regression occurred in the rollup , and the second occurred sometime in the two weeks between changes ... There is heavy use of async/await in the code, and I've identified a couple places where taking out makes the compile finish right away. This makes me suspect for the first regression, but I'm not sure. I'll update the issue as I have more information.
Interestingly, removing from either of these places makes the compile much faster. If I leave both in, it's slow, but taking one or both out makes it faster. Maybe there's some kind of cycle being created when both are left in? In fact, switching on actually causes a cycle error to be reported when there wasn't one before. This is really weird to me, but it may be a red herring. Removing one or both of the calls (or calls to the methods that create the futures) doesn't resolve the cycle error, even though it resolves the slowdown. of the error, for completeness.
I don't have a lot more information to put here, except that the compile time seems to increase with the size of a particular call graph of async fns (it's not binary slow/fast, but different gradations of slow). This continues to make it hard to minimize. I did some profiling, and noticed a lot of time being spent collecting items in . Unfortunately I couldn't see what was calling that function. There was some speculation that it could be from (cc who suggested this). See for more details, and some flame graphs of the profiles I ran.
visited for T-compiler triage. Assigning P-high based on labels applied by niko as part of async-await triage. Removing nomination label too.
Change:
.is_ok() }) } <ins> (&BuiltinCandidate(_), &ParamCandidate(_)) => { // If we have a where-clause like `Option<K> : Send`, // then we wind up in a situation where there is a // default rule (`Option<K>:Send if K:Send) and the // where-clause that both seem applicable. Just take // the where-clause in that case. true } </ins> (&ProjectionCandidate, &ParamCandidate(_)) => { // FIXME(#20297) -- this gives where clauses precedent // over projections. Really these are just two means

Discussion:
The following program: dies with a false ambiguity report. The problem is that the builtin bound rules kick and identify that , but there is also a where-clause for that same thing. We should treat builtin-bounds expansions in the same was an explicit impl and resolve in favor of the where-clause.
Change:
/// /// Behavior is undefined if any of the following conditions are violated: /// <del> /// * `src` must be [valid] for reads of `count * size_of::<T>()` bytes. </del> <ins> /// * `src` must be [valid] for reads of `count * size_of::<T>()` bytes, and must remain valid even ///   when `dst` is written for `count * size_of::<T>()` bytes. (This means if the memory ranges ///   overlap, the two pointers must not be subject to aliasing restrictions relative to each ///   other.) </ins> /// <del> /// * `dst` must be [valid] for writes of `count * size_of::<T>()` bytes. </del> <ins> /// * `dst` must be [valid] for writes of `count * size_of::<T>()` bytes, and must remain valid even ///   when `src` is read for `count * size_of::<T>()` bytes. </ins> /// /// * Both `src` and `dst` must be properly aligned. ///

Discussion:
The  function allows passed pointers to overlap, and its safety section is as follows: It says that both pointers must be "valid," but IIUC, the definition of validity becomes unclear under Stacked Borrows. Consider the following program (all code in this comment is checked using Miri with ): and are both "valid" at in the sense that this program is safe. is invalidated when we perform a write using , but it's ok because we don't use anymore. However, the following program exhibits UB in spite of the validity of and , because first reads from and the read invalidates . Note that the intermediate unique reference () is crucial for "separating" the two pointers. If we remove the intermediate reference, those pointers have the same capabilities. In other words, the following program does not exhibit UB: The difference between the two examples is so subtle that I'm not sure how to spell out the exact safety conditions for . This issue is found while formalizing the safety of in the Rustv project.
By the way, of contains unrelated UB. The example calls  twice, which accidentally invalidates the first pointer .
possibly related:
cc
The same argument seems to apply to . Miri (tracking raw pointers) reported undefined behavior for the following code: When I set the argument of the to 1, Miri did not report any undefined behavior. This may be an implementation detail. <details</detailsNote that the pointers are valid individually but not simultaneously in these examples. I found this distinction very interesting, but I don't know how to explain this without being too scholarly
Well, they are valid individually, but they are not "both valid at the same time". In separation logic terms, we have but we do not have . The issue is to find a way to express that without using separation logic terminology.^^ is entirely unrelated, as it concerns the safety invariant of and the soundness of its method in ways other than aliasing. is an example of code that uses* the wrong way, at least wrong under Stacked Borrows. So it is the dual issue -- it is a consumer if the spec which this issue points could needs to be made more precise.
Change:
Some(name) => bug!("unknown target feature gate {}", name), None => true, }; <del> if !allowed { </del> <ins> if !allowed && id.is_local() { </ins> feature_gate::emit_feature_err( &tcx.sess.parse_sess, feature_gate.as_ref().unwrap(),

Discussion:
Given this code: it compiles as: How odd!
Not technically a regression but this needs to be fixed before 1.27 hits stable, so tagging as a nightly regression

Given: and you'll see: But that's not right! Only the original crate should need this directive, and it indeed has such a directive.
Change:
// call's arguments and we can provide a more explicit span. let sig = self.tcx.fn_sig(def_id).subst_identity(); let def_self_ty = sig.input(0).skip_binder(); <ins> let param_tys = sig.inputs().skip_binder().iter().skip(1); // If there's an arity mismatch, pointing out the call as the source of an inference // can be misleading, so we skip it. if param_tys.len() != args.len() { continue; } </ins> let rcvr_ty = self.node_ty(rcvr.hir_id); // Get the evaluated type *after* calling the method call, so that the influence // of the arguments can be reflected in the receiver type. The receiver

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:
* * # Failure * <del> * Fails if invalid UTF-8 </del> <ins> * Raises the `not_utf8` condition if invalid UTF-8 </ins> */ <del> pub fn from_bytes(vv: &const [u8]) -> ~str { assert!(is_utf8(vv)); return unsafe { raw::from_bytes(vv) }; </del> <ins> pub fn from_bytes(vv: &[u8]) -> ~str { use str::not_utf8::cond; if !is_utf8(vv) { let first_bad_byte = vec::find(vv, |b| !is_utf8([*b])).get(); cond.raise(fmt!("from_bytes: input is not UTF-8; first bad byte is %u", first_bad_byte as uint)) } else { return unsafe { raw::from_bytes(vv) } } </ins> } /**

Discussion:
It seems to me that returning a Result would be more appropriate than failing.
See discussion on -- the right thing to do here would be to use conditions, I think.
This should be pretty simple -- working on it.
Fixed pending
fixes.
Change:
/// Returns the span for the "end point" given region. This will /// return `None` if NLL is enabled, since that concept has no <del> /// meaning there.  Otherwise, it should return some. </del> <ins> /// meaning there.  Otherwise, return region span if it exists and /// span for end of the function if it doesn't exist. </ins> pub fn opt_region_end_span(&self, region: &Region) -> Option<Span> { <del> let opt_span = self.region_span_map.get(region); assert!(self.nonlexical_regioncx.is_some() || opt_span.is_some(), "end region not found for {:?}", region); opt_span.map(|s| s.end_point()) </del> <ins> match self.nonlexical_regioncx { Some(_) => None, None => { match self.region_span_map.get(region) { Some(span) => Some(span.end_point()), None => Some(self.mir.span.end_point()) } } } </ins> } /// Add all borrows to the kill set, if those borrows are out of scope at `location`.

Discussion:
MIR borrowck ICEs when an error involving a region whose EndRegion is missing occurs (this occurs when a region can never end within the function). Instead it should emit a correct diagnostic. This can occur for both free regions (e.g. issue-): And for infinite loops: Causing this ICE:
The ICE here is caused by the assert in this function, : This function finds the (location in the input source code) that a region ends. If you look at the error that the AST borrowck (i.e., older style borrowck) emits, we are basically computing the point where to write that "immutable borrow ends here" message: Right now, there is a kind of complicated assertion. It is saying that one of two things should be: We are in non-lexical mode. In that case, there are no end-regions at all, so we just return . This causes us not to write "immutable borrow ends here". We are in lexical mode, in which case we should have found an statement. These are special statements we insert into the MIR (only in lexical mode) that tell us where the various lexical lifetimes end. The problem is that in cases where the region never properly ends, we won't find an statement. I think what we want to do is rewrite the function a bit. If we are in NLL mode (), then we should always return . Otherwise, check the as we are doing and return if we find something in there, as we are doing now. Otherwise, we want to return the span for the end of the function. This is the new part. As it happens, we can get this by returning : is the MIR for the function we are checking is the span in the source code where the function is defined returning its end point should, I think, give us the behavior we want. So, when we are done, if is , this function should always return for some span, but sometimes it will be the end of the function.
Hi, I want to work on this bug.
Change:
CFG_LIBDIR_RELATIVE=bin fi <ins> if [ "$CFG_OSTYPE" = "pc-mingw32" ] || [ "$CFG_OSTYPE" = "w64-mingw32" ] then CFG_LD_PATH_VAR=PATH CFG_OLD_LD_PATH_VAR=$PATH elif [ "$CFG_OSTYPE" = "Darwin" ] then CFG_LD_PATH_VAR=DYLD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$DYLD_LIBRARY_PATH else CFG_LD_PATH_VAR=LD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$LD_LIBRARY_PATH fi </ins> flag uninstall "only uninstall from the installation prefix" opt verify 1 "verify that the installed binaries run correctly" valopt prefix "/usr/local" "set installation prefix"

Discussion:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)
Change:
# LTO entirely. #lto = "thin-local" <ins> # Build compiler with the optimization enabled and -Zvalidate-mir, currently only for `std` #validate-mir-opts = 3 </ins> # ============================================================================= # Options for specific targets #

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.