jiebi/CodeConvo huggingface dataset:
Change:
* receiver and method generics. */ <del> // determine how many type parameters were declared on the impl let num_impl_type_parameters = { let impl_polytype = ty::lookup_item_type(tcx, impl_id); impl_polytype.generics.type_param_defs().len() }; // determine how many type parameters appear on the trait let num_trait_type_parameters = trait_ref.substs.tps.len(); // the current method type has the type parameters from the trait + method let num_method_type_parameters = num_trait_type_parameters + method.generics.type_param_defs().len(); // the new method type will have the type parameters from the impl + method let combined_tps = Vec::from_fn(num_method_type_parameters, |i| { if i < num_trait_type_parameters { // replace type parameters that come from trait with new value *trait_ref.substs.tps.get(i) } else { // replace type parameters that belong to method with another // type parameter, this time with the index adjusted let method_index = i - num_trait_type_parameters; let type_param_def = &method.generics.type_param_defs()[method_index]; let new_index = num_impl_type_parameters + method_index; ty::mk_param(tcx, new_index, type_param_def.def_id) </del> <ins> let impl_polytype = ty::lookup_item_type(tcx, impl_id); let num_impl_tps = impl_polytype.generics.type_param_defs().len(); let num_impl_regions = impl_polytype.generics.region_param_defs().len(); let meth_tps: Vec<ty::t> = method.generics.type_param_defs().iter().enumerate() .map(|(i, t)| ty::mk_param(tcx, i + num_impl_tps, t.def_id)) .collect(); let meth_regions: Vec<ty::Region> = method.generics.region_param_defs().iter().enumerate() .map(|(i, l)| ty::ReEarlyBound(l.def_id.node, i + num_impl_regions, l.name)) .collect(); let mut combined_tps = trait_ref.substs.tps.clone(); combined_tps.push_all_move(meth_tps); let combined_regions = match &trait_ref.substs.regions { &ty::ErasedRegions => fail!("make_substs_for_receiver_types: unexpected ErasedRegions"), &ty::NonerasedRegions(ref rs) => { let mut rs = rs.clone().into_vec(); rs.push_all_move(meth_regions); ty::NonerasedRegions(OwnedSlice::from_vec(rs)) </ins> } <del> }); </del> <ins> }; </ins> <del> return ty::substs { regions: trait_ref.substs.regions.clone(), </del> <ins> ty::substs { regions: combined_regions, </ins> self_ty: trait_ref.substs.self_ty, tps: combined_tps <del> }; </del> <ins> } </ins> } fn subst_receiver_types_in_method_ty(tcx: &ty::ctxt,

Discussion:
Not exactly sure what the minimal failing test case is yet.
I think that I was running an out of date rustc. I don't think that this is a problem on master.
Actually, I hit this on rustc that I just built from master.
I talked to and he gave me access to his codebase, which I used to narrow down: Converting to a normal trait method and implementing it for stops the ICE. cc
Change:
// above `RawVec::grow_amortized` for details. (The `A` parameter isn't // significant, because the number of different `A` types seen in practice is // much smaller than the number of `T` types.) <ins> #[inline(never)] </ins> fn finish_grow<A>( new_layout: Result<Layout, LayoutError>, current_memory: Option<(NonNull<u8>, Layout)>,

Discussion:
The change in made non-PGO builds of Firefox's 's .text section grow by close to 1MB. has a ~89MB section, which makes it a 1% size increase in a library where about only 16% of the code is rust, which makes it a 7% (!) increase in size. This comes from the fact that essentially all uses of Vec::push inline this all for some reason, and it's used all across the place.
modify labels: I-heavy T-libs
Error: Label libs-impl can only be set by Rust team members Please let know if you're having trouble with this bot.
inling seems to have a noticable performance benefit, so not doing so is probably not desirable, see Not sure how else we would be able to directly remedy this issue.
Assigning as and removing .
Change:
<ins> // run-rustfix struct Foo; impl std::ops::Mul for &Foo { type Output = Foo; fn mul(self, _rhs: Self) -> Self::Output { unimplemented!() } } fn main() { let ref_mut_foo: &mut Foo = &mut Foo; let ref_foo: &Foo = &Foo; let owned_foo: Foo = Foo; let _ = ref_foo * ref_foo; let _ = ref_foo * ref_mut_foo; let _ = ref_mut_foo * ref_foo; //~^ ERROR cannot multiply let _ = ref_mut_foo * ref_mut_foo; //~^ ERROR cannot multiply let _ = ref_mut_foo * &owned_foo; //~^ ERROR cannot multiply } </ins>

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
GenericArgKind::Lifetime(lt) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*lt.0.0) & TAG_MASK, 0); <del> (REGION_TAG, lt.0.0 as *const ty::RegionKind<'tcx> as usize) </del> <ins> (REGION_TAG, NonNull::from(lt.0.0).cast()) </ins> } GenericArgKind::Type(ty) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ty.0.0) & TAG_MASK, 0); <del> (TYPE_TAG, ty.0.0 as *const WithCachedTypeInfo<ty::TyKind<'tcx>> as usize) </del> <ins> (TYPE_TAG, NonNull::from(ty.0.0).cast()) </ins> } GenericArgKind::Const(ct) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ct.0.0) & TAG_MASK, 0); <del> (CONST_TAG, ct.0.0 as *const WithCachedTypeInfo<ty::ConstData<'tcx>> as usize) </del> <ins> (CONST_TAG, NonNull::from(ct.0.0).cast()) </ins> } }; <del> GenericArg { ptr: unsafe { NonZeroUsize::new_unchecked(ptr | tag) }, marker: PhantomData } </del> <ins> GenericArg { ptr: ptr.map_addr(|addr| addr | tag), marker: PhantomData } </ins> } }

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
<ins> error[E0308]: mismatched types --> $DIR/sugg-else-for-closure.rs:6:26 | LL |     let _s = y.unwrap_or(|| x.split('.').nth(1).unwrap()); |                --------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `&str`, found closure |                | |                arguments to this function are incorrect | = note: expected reference `&str` found closure `[closure@$DIR/sugg-else-for-closure.rs:6:26: 6:28]` note: associated function defined here --> $SRC_DIR/core/src/option.rs:LL:COL | LL |     pub const fn unwrap_or(self, default: T) -> T |                  ^^^^^^^^^ help: try calling `unwrap_or_else` instead | LL |     let _s = y.unwrap_or_else(|| x.split('.').nth(1).unwrap()); |                         +++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. 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. --should suggest if the argument is a closure instead of suggesting to call the closure Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This probably can be generalized if the code is written carefully enough.
Do you mean, we should handle other types like which may use with a closure?
I know nothing about the internals of rustc diagnostics but a general way would be to check if a similar method in name accepts a closure and suggest that first, if nothing similar can be found then suggest calling the closure
I mean something more like what is suggesting, where you check if exists whose signature is compatible with a closure. But that requires doing a method probe, then doing some delicate logic to check argument compatibility.
Change:
<ins> error[E0530]: match bindings cannot shadow const parameters --> $DIR/shadow-const-param.rs:7:9 | LL | fn foo<const N: i32>(i: i32) -> bool { |              - the const parameter `N` is defined here LL |     match i { LL |         N @ _ => true, |         ^ cannot be named the same as a const parameter error[E0530]: let bindings cannot shadow const parameters --> $DIR/shadow-const-param.rs:13:9 | LL | fn bar<const N: i32>(i: i32) -> bool { |              - the const parameter `N` is defined here LL |     let N @ _ = 0; |         ^ cannot be named the same as a const parameter error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0530`. </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-medium
Change:
} #[test] <ins> fn test_from_cstr_len() unsafe { let a = [65u8, 65u8, 65u8, 65u8, 65u8, 65u8, 65u8, 0u8]; let b = vec::to_ptr(a); let c = from_cstr_len(b, 3u); assert (c == "AAA"); } #[test] </ins> fn test_as_buf() unsafe { let a = "Abcdefg"; let b = as_buf(a, {|buf| assert (*buf == 65u8); 100 });

Discussion:
We have a function str::fromcstr but it assumes that C string is null-terminated. The only way I see to build a string from a non-null-terminated buffer is using str::frombytes(vec::from_buf()) which requires an extra copy of the string.
Change:
<ins> error[E0599]: no function or associated item named `try_from` found for type parameter `T` in the current scope --> $DIR/missing-method-on-type-parameter.rs:3:8 | LL | fn x<T: Copy>() { |      - function or associated item `try_from` not found for this type parameter LL |     T::try_from(); |        ^^^^^^^^ function or associated item not found in `T` | = help: items from traits can only be used if the trait is in scope help: there is an associated function `from` with a similar name --> $SRC_DIR/core/src/convert/mod.rs:LL:COL help: trait `TryFrom` which provides `try_from` is implemented but not in scope; perhaps you want to import it | LL + use std::convert::TryFrom; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
visit::walk_generics(this, generics); // Walk the generated arguments for the `async fn`. <del> for a in arguments { </del> <ins> for (i, a) in arguments.iter().enumerate() { </ins> use visit::Visitor; if let Some(arg) = &a.arg { this.visit_ty(&arg.ty); <ins> } else { this.visit_ty(&decl.inputs[i].ty); </ins> } }

Discussion:
I was using nightly rust extensively for its async/await and specialization feature. After a recent update (nightly-2019-05-02), a new ICE introduced with following logs: After a quick search it seems like is the only in direct cause (stack frame 10). ~I cannot share the code or produce a minimal case because the code base is rather big.~
I've the minimal case for reproducing. Hope that would help!
Thanks! Looks like even this line is enough to trigger the ICE:
: rustc complains you should have variable mut although it is already mut.
That's and should be fixed in the next nightly
cc it looks like the desugaring may have broken in argument-position?
Oops, sorry. I'll take a look.
Denominating since already has a fix
Thanks guys! This is a super fast fix!
Change:
/// /// [`reserve`]: ../ffi/struct.OsString.html#method.reserve /// [`OsString`]: ../ffi/struct.OsString.html <del> #[unstable(feature = "path_buf_capacity", issue = "58234")] </del> <ins> #[stable(feature = "path_buf_capacity", since = "1.44.0")] </ins> pub fn reserve(&mut self, additional: usize) { self.inner.reserve(additional) }

Discussion:
, should probably not be stabilized before , see
Happy to take this on as a first contribution to rust.
Great! I'd be happy to help you get started, just let me know if you want mentoring/instructions at any level!
are you able to define a list of the methods that need to be implemented as part of this PR?
I think all of these will essentially call the underlying functions on . [ ] [ ] [ ] [ ] [ ] [ ] [ ] -- this one is more of a maybe, since it's unstable on OsString. We can reuse the same tracking issue for this. We'll probably want to add all of these under the same feature gate.
thanks for that. I have the implementation drafted locally. I'm having some difficulty however in running the tests for stdlib - even a is producing errors not related to my changes. Is there any documentation I've missed for best practices on compiling / working on stdlib?
You'll want to use x.py; for your scenario I believe and/or are the commands you want. I'm not sure where the most current documentation is.
describes how to use .
Triage: since has been merged, can this be closed?
No, this is now the tracking issue for the stabilization of those APIs.
Reviewing this since then, I think it may be worth removing these APIs and replacing them with something like and . These aren't really commonly used so hiding them as such seems reasonable and is less heavy.
I'd love to see these stabilized. I have a tool that manipulates lots of paths, so I'd like to avoid needless reallocations. I generate lots of temporary paths in a loop. would work nicely to reuse the buffer. I need to concatenate several components. I know their length, so I could use I want to store lots of paths for later. is a bit smaller than , but if I can't reserve exact capacity, will reallocate.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See for info about what commands tagged team members can give me.
reviewed assuming we're only stabilizing capacity + withcapacity + clear + reserve + reserveexact + shrinktofit;&ensp;and shrink_to is being moved to instead.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I've posted a stabilization PR in .
Change:
#[inline] #[experimental = "not triaged yet"] fn is_empty(&self) -> bool { self.len() == 0 } /// Returns a mutable reference to the element at the given index, /// or `None` if the index is out of bounds #[unstable = "waiting on final error conventions"]

Discussion:
As titled. Although slices support the operator, it does not implement , so one cannot pass in a slice in the following example:
I'm somewhat inclined to think we could just remove the built-in indexing from entirely and thus remove/reduce the need for the special lang-items, although there's at least three considerations: the failure message for out-of-bounds indexing would be less informative (no file/line information), but debugging any other (e.g. ) already requires a debugger to get this info, so maybe it's not so bad. can't yet implement properly, so this would still need built-in support with (and thus the out-of-bounds failure lang items can't be entirely removed just yet), unless implicit coercions will work. needs to be fixed before will work properly (and I guess DST would make it work more nicely). Users would theoretically not see a change, since this would all happen inside (and ).
It's not possible due to lack of CTFE.
cc me
Should I send a PR implementing / for now, and we can evaluate later removing the built-in indexing? I already tested that PR, and the built-in indexing is preferred in the operation , but one go through the trait using .
Yes, please go ahead and do so. Thanks!
Change:
fn emit_frag_parse_err( mut e: DiagnosticBuilder<'_>, parser: &Parser<'_>, <ins> orig_parser: &mut Parser<'_>, </ins> site_span: Span, macro_ident: ast::Ident, arm_span: Span,

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
// revisions: i586_unknown_netbsd // [i586_unknown_netbsd] compile-flags: --target i586-unknown-netbsd // [i586_unknown_netbsd] needs-llvm-components: x86 <del> // revisions: i686_apple_darwin // [i686_apple_darwin] compile-flags: --target i686-apple-darwin // [i686_apple_darwin] needs-llvm-components: x86 </del> // revisions: i686_linux_android // [i686_linux_android] compile-flags: --target i686-linux-android // [i686_linux_android] needs-llvm-components: x86

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.