jiebi/CodeConvo huggingface dataset:
Change:
pub fn LLVMConstInt(IntTy: &Type, N: c_ulonglong, SignExtend: Bool) -> &Value; pub fn LLVMConstIntOfArbitraryPrecision(IntTy: &Type, Wn: c_uint, Ws: *const u64) -> &Value; pub fn LLVMConstReal(RealTy: &Type, N: f64) -> &Value; <del> pub fn LLVMConstIntGetZExtValue(ConstantVal: &ConstantInt) -> c_ulonglong; </del> <ins> pub fn LLVMRustConstIntGetZExtValue(ConstantVal: &ConstantInt, Value: &mut u64) -> bool; </ins> pub fn LLVMRustConstInt128Get( ConstantVal: &ConstantInt, SExt: bool,

Discussion:
Array created using repeat expression and returned from a function actually returns . Interestingly the problem does not happen when using the list syntax to create the array. I tried this code: I expected to see this happen: the second should pass Instead, this happened: the second fails screaming that Problem exists on stable, beta and nightly : <details<summaryBacktrace</summary<p</p</details
I wonder if is at fault here. It does look to be inappropriately turning the repeat into a memset (when looking at the llvm IR)
Compiling this: with Yields: Which does not seem right. We shouldn't be emitting a memset to 0 there.
This program hits an LLVM assertion if compiled with an LLVM that has assertions enabled:
This appeared in . Until the sample would code emit a compile error (), maybe that would shadow the error? A bisection between those two stable releases points to a group of old PR but I can't really pinpoint one :/
fails even under 1.26. And before that, i128 didn't even exist. So this has been a problem since 128 bit ints were introduced, as far as I can see.
Thank you for the analysis and the fix :)
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
macro_rules! assert_unsafe_precondition { ($message:expr, ($($name:ident:$ty:ty = $arg:expr),*$(,)?) => $e:expr $(,)?) => { { <del> #[inline(never)] </del> <ins> // When the standard library is compiled with debug assertions, we want the check to inline for better performance. // This is important when working on the compiler, which is compiled with debug assertions locally. // When not compiled with debug assertions (so the precompiled std) we outline the check to minimize the compile // time impact when debug assertions are disabled. // It is not clear whether that is the best solution, see #120848. #[cfg_attr(debug_assertions, inline(always))] #[cfg_attr(not(debug_assertions), inline(never))] </ins> #[rustc_nounwind] fn precondition_check($($name:$ty),*) { if !$e {

Discussion:
The compiler compiled with debug assertions has gotten really slow recently. For example, compiling the standard library takes way longer than it used to. This is bad, it makes it way harder to work on rustc.
This is probably because of the recent changes to . It contains a cfg(bootstrap) hack for that's not inlined. Additionally, it outlines the predicate, which is super slow as well. Fixing the former is easy, fixing the latter is harder and requires adding .
turns out this was caused by many different factors compounding in an unfortunate way :D oli's intrinsic changes outlining some important functions, and the unsafe preconditions being quite bad for runtime performance
Change:
useful for allowing safe, efficient access to a portion of an array without copying. For example, you might want to reference just one line of a file read into memory. By nature, a slice is not created directly, but from an existing <del> variable. Slices have a length, can be mutable or not, and in many ways behave like arrays: </del> <ins> variable binding. Slices have a defined length, can be mutable or immutable. ## Slicing syntax You can use a combo of `&` and `[]` to create a slice from various things. The `&` indicates that slices are similar to references, and the `[]`s, with a range, let you define the length of the slice: </ins> ```rust let a = [0, 1, 2, 3, 4]; <del> let middle = &a[1..4]; // A slice of a: just the elements 1, 2, and 3 </del> let complete = &a[..]; // A slice containing all of the elements in a <ins> let middle = &a[1..4]; // A slice of a: just the elements 1, 2, and 3 </ins> ``` Slices have type `&[T]`. We’ll talk about that `T` when we cover

Discussion:
The section of the Rust book on Slices is nice (hard to find in primitive types) but it gives more information on : The actual docs for slice just intro it out of nowhere with no explanation of the fact that it's syntactic sugar for as_slice. This is a subtle thing, but since googling for [..] is hard and github searching for "[..]" is basically impossible, it's a tough thing to have to search out, let alone explain on the web. Thanks! Anyway, great documentation, hard to search for without single page, but I would want to fix the docs in libcollections if possible since ideally it would have more information and detail there. -Rich
cc I completely agree that this is a bit weird right now. I'd like to add something, but I'm not sure what form it should take.
It doesn't seem like is defined in rust nightly. Playground link:
In general, is behind the feature gate, and should be used instead.
Ah. That explains it. So it seems like and are actually different things, because one is behind a feature gate, and one is not. Am I right about this?
They do the same thing. The syntax was later, one of the motivations was that is common and quite long, as well as an inexpensive operation.
:+1: to this, it's totally ungoogleable, from the reference I concluded it's an use of the range operator, the book section could mention it.
Change:
} // See note at the top of this module to understand why these are used: <ins> // // These casts are safe as OsStr is internally a wrapper around [u8] on all // platforms. // // Note that currently this relies on the special knowledge that libstd has; // these types are single-element structs but are not marked repr(transparent) // or repr(C) which would make these casts allowable outside std. </ins> fn os_str_as_u8_slice(s: &OsStr) -> &[u8] { unsafe { &*(s as *const OsStr as *const [u8]) } }

Discussion:
Hey, I'm curious about the . From what I understand: this works because Path is a single member struct containing only the type it's being reinterpreted as. My original question on #rust IRC was: Is this always guaranteed to be correct (in Rust) in terms of memory layout? The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs. I would love some clarification if this usage is correct or to what degree it is not. I'd also suggest we add clarification around this case with comments or support functions to aid future spelunking into std.
No, strictly speaking, this is not safe without .
excellent, thank you! The seems to indicate things going slowly. Adding a comment might still be a good idea for now. Reading the RFC, it mentions at least ARM64 where there might be layout differences. But according to , std shows up as supported as a Tier 2 platform. This implies that at least for now, this pattern in this instance () works. Is this correct?
That ARM64 issue seems to be related to calling convention, not memory layout, so it's not an issue here.
This is my understanding as well. I believe it is safe with either repr(transparent) or repr(C), the latter of which is stable. The  crate is a generalization of this safe cast.
Change:
/// We currently don't iterate over this map, but if we do in the future, /// switch it back to `FxIndexMap` to avoid query stability hazards. bcb_edge_counters: FxHashMap<(BasicCoverageBlock, BasicCoverageBlock), BcbCounter>, <del> /// Tracks which BCBs have a counter associated with some incoming edge. /// Only used by assertions, to verify that BCBs with incoming edge /// counters do not have their own physical counters (expressions are allowed). bcb_has_incoming_edge_counters: BitSet<BasicCoverageBlock>, </del> /// Table of expression data, associating each expression ID with its /// corresponding operator (+ or -) and its LHS/RHS operands. expressions: IndexVec<ExpressionId, Expression>,

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' 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: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
pub fn check_crate(krate: &ast::Crate, sess: &Session) { maybe_stage_features(sess, krate); <ins> check_incompatible_features(sess); </ins> let mut visitor = PostExpansionVisitor { sess, features: &sess.features_untracked() }; let spans = sess.parse_sess.gated_spans.spans.borrow();

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .
Change:
<ins> // Regression test for the ICE described in #86721. // revisions: rev1 rev2 #![cfg_attr(any(), rev1, rev2)] #![crate_type="lib"] #[cfg(any(rev1))] trait T { const U: usize = return; //[rev1]~^ ERROR: return statement outside of function body [E0572] } #[cfg(any(rev2))] trait T2 { fn foo(a: [(); return]); //[rev2]~^ ERROR: return statement outside of function body [E0572] } </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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This is a regression considering it doesn't happen in beta.
Change:
} } <del> impl Visitor<'_> for CanConstProp { </del> <ins> impl<'tcx> Visitor<'tcx> for CanConstProp { fn visit_place(&mut self, place: &Place<'tcx>, mut context: PlaceContext, loc: Location) { use rustc_middle::mir::visit::PlaceContext::*; // Dereferencing just read the addess of `place.local`. if place.projection.first() == Some(&PlaceElem::Deref) { context = NonMutatingUse(NonMutatingUseContext::Copy); } self.visit_local(place.local, context, loc); self.visit_projection(place.as_ref(), context, loc); } </ins> fn visit_local(&mut self, local: Local, context: PlaceContext, _: Location) { use rustc_middle::mir::visit::PlaceContext::*; match context { <del> // Projections are fine, because `&mut foo.x` will be caught by // `MutatingUseContext::Borrow` elsewhere. MutatingUse(MutatingUseContext::Projection) </del> // These are just stores, where the storing is not propagatable, but there may be later // mutations of the same local via `Store` | MutatingUse(MutatingUseContext::Call)

Discussion:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use std::borrow::Cow; </ins> use std::cmp::Ordering::{Equal, Greater, Less}; use std::str::from_utf8;

Discussion:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?
Change:
match self.log_out { None => (), Some(ref mut o) => { <del> let s = format!("{} {}", match *result { </del> <ins> let s = format!("{} {}n", match *result { </ins> TrOk => ~"ok", TrFailed => ~"failed", TrIgnored => ~"ignored",

Discussion:
The final summary at the end says we ran 28 tests when we ran thousands.
Interesting, is the code for buildbot in src/test?
This code is part of the build system. is the place to start looking. The code for recording the number of tests is probably in .
Thanks brson, You were right, the code is in extra::test. Do I execute the tests through:
I'll pick this up, unless it's still in-progress or has been fixed already.
Go for it, I'd love to see what you come up with!
Change:
use externalfiles::ExternalHtml; <del> use serialize::json::{self, ToJson}; </del> <ins> use serialize::json::{ToJson, Json, as_json}; </ins> use syntax::{abi, ast}; use syntax::feature_gate::UnstableFeatures; use rustc::middle::cstore::LOCAL_CRATE;

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
pub fn multipart_suggestion_with_style( &mut self, msg: impl Into<SubdiagnosticMessage>, <del> suggestion: Vec<(Span, String)>, </del> <ins> mut suggestion: Vec<(Span, String)>, </ins> applicability: Applicability, style: SuggestionStyle, ) -> &mut Self { <del> let mut parts = suggestion </del> <ins> suggestion.sort_unstable(); suggestion.dedup(); let parts = suggestion </ins> .into_iter() .map(|(span, snippet)| SubstitutionPart { snippet, span }) .collect::<Vec<_>>(); <del> parts.sort_unstable_by_key(|part| part.span); </del> assert!(!parts.is_empty()); debug_assert_eq!( parts.iter().find(|part| part.span.is_empty() && part.snippet.is_empty()),

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
Probably just worth ignoring placeholder suggestions if they are coming from a different span ctxt than the fn -- either that, or logic to detect reuses of the same or something. Anyways, I think this is minimal: But I can't test it since I'm on my laptop.
Yeah can confirm this also triggers the debug assertion ^
Change:
/// Returns the creation time listed in this metadata. /// <del> /// The returned value corresponds to the `birthtime` field of `stat` on /// Unix platforms and the `ftCreationTime` field on Windows platforms. </del> <ins> /// The returned value corresponds to the `btime` field of `statx` on /// Linux kernel starting from to 4.11, the `birthtime` field of `stat` on other /// Unix platforms, and the `ftCreationTime` field on Windows platforms. </ins> /// /// # Errors /// /// This field may not be available on all platforms, and will return an <del> /// `Err` on platforms where it is not available. </del> <ins> /// `Err` on platforms or filesystems where it is not available. </ins> /// /// # Examples ///

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
span: codemap::Span) -> IoResult<()> { try!(self.print_ident(ident)); try!(self.print_generics(generics)); <del> try!(self.print_where_clause(generics)); </del> if ast_util::struct_def_is_tuple_like(struct_def) { if !struct_def.fields.is_empty() { try!(self.popen());

Discussion:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.
Change:
<ins> #![feature(return_position_impl_trait_in_trait)] #![allow(incomplete_features)] trait Marker {} impl Marker for u32 {} trait MyTrait { fn foo(&self) -> impl Marker where Self: Sized; } struct Outer; impl MyTrait for Outer { fn foo(&self) -> impl Marker { 42 } } impl dyn MyTrait { fn other(&self) -> impl Marker { MyTrait::foo(&self) //~^ ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied //~| ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied //~| ERROR the trait bound `&dyn MyTrait: MyTrait` is not satisfied } } fn main() {} </ins>

Discussion:
Based on 's blog posts, I was playing around with RPITIT and dyn Trait. I fully understand that it shouldn't compile :sweat_smile:. It should probably give the same error as you get when is replaced with . Which would be: . Playground: <strongDetails:</strongI started with this code ("shadowing foo" and dot-notation): Which errors with , but recommends the ICE-ing code: . ICE's both on nightly and beta. <details<summary<strongBacktrace 1</strong</summary<p</p</details<details<summary<strongBacktrace 2</strong</summary<p</p</details
the that triggers. Maybe including is enough to fix it?
No, that will just mask the underlying issue.
label +F-returnpositionimpltraitin_trait
Change:
<ins> // check-pass struct S( #[rustfmt::skip] u8, u16, #[rustfmt::skip] u32, ); fn main() {} </ins>

Discussion:
Stable, and nightly-2019-09-09: nightly-2019-09-10: Mentioning because this is likely from .
Yeah, this is some known shortcut taken in , sorry. Didn't expect people to hit it that fast. Will fix ~this weekend.
Thanks. The realistic usage where this appears is if you forget to import a derive macro, which happens commonly.
Un-nominating since Vadim self-assigned.
triage: P-high.
Fixed in
Change:
/// [`spawn`]: ../../std/thread/struct.Builder.html#method.spawn /// [`io::Result`]: ../../std/io/type.Result.html /// [`unwrap`]: ../../std/result/enum.Result.html#method.unwrap <ins> /// [naming-threads]: ./index.html#naming-threads /// [stack-size]: ./index.html#stack-size </ins> #[stable(feature = "rust1", since = "1.0.0")] #[derive(Debug)] pub struct Builder {

Discussion:
One can specify the stack size of a thread via . It looks like looks at the env var and attempts to parse it into an integer. If it's not specified or can't parse, it falls back to 2MB. Should we update the thread documentation to mention what the default stack size is and mention that environment variable?
Relevant discussion on IRC
Don't forget that the stack size of the main thread is not determined by Rust.
Opened a PR: