jiebi/CodeConvo huggingface dataset:
Change:
/// # Examples /// /// ``` <del> /// #![feature(path_buf_capacity)] </del> /// use std::path::PathBuf; /// /// let mut path = PathBuf::with_capacity(10);

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:
&impl_trait_ref.substs); } None => { <del> tcx.sess.span_err( </del> <ins> // This is span_bug as it should have already been caught in resolve. tcx.sess.span_bug( </ins> impl_method.span, format!( "method `{}` is not a member of trait `{}`",

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
pub fn good6(s: StructWithProjectionAndLifetime); pub fn good7(fptr: extern fn() -> ()); pub fn good8(fptr: extern fn() -> !); <ins> pub fn good9() -> (); pub fn good10() -> CVoidRet; </ins> } fn main() {

Discussion:
made the lint trigger for tuples, but as far as I understand, returning is equivalent to returning cvoid, and therefore should be allowed. Here is an example:
Yes, stupid mistake; I'll fix it. (As a workaround, you can write .)
since was merged i'm closing
Change:
found type `{integer}` error[E0308]: mismatched types <del> --> $DIR/return-ty-mismatch-note.rs:8:6 </del> <ins> --> $DIR/return-ty-mismatch-note.rs:9:6 </ins> | LL | fn g<U, V>() -> (U, V) { |      - expected this type parameter

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
)] #![cfg_attr( not(bootstrap), <del> doc(cfg_hide(not(test), not(any(test, bootstrap)), target_has_atomic = "ptr")) </del> <ins> doc(cfg_hide( not(test), not(any(test, bootstrap)), any(not(feature = "miri-test-libstd"), test, doctest), target_has_atomic = "ptr" )) </ins> )] #![no_std] #![needs_allocator]

Discussion:
shows this annotation: This doesn't seem very useful for an end-user, and this annotation shows for every page in the documentation. This issue also affects crate.
the fix is to add to the crate root; it would be a good first PR :)
Change:
<ins> error: opaque types cannot be used in patterns --> $DIR/issue-71042-opaquely-typed-constant-used-in-pattern.rs:7:9 | LL |         C | _ => {} |         ^ error: aborting due to previous error </ins>

Discussion:
ICE message: <details<summaryBacktrace</summary</summary
This should be erroring in exhaustiveness checking; shouldn't be allowed there. cc
It should be erroring earlier, when trying to create a pattern out of the constant. And it should also not be considered structural-match type-wise.
Triage: This is no longer ICE, seems that it's fixed by , marking as E-needs-test.

gives: My guess is that this has the same underlying cause as , but this one doesn't involve associated consts or arrays at all, so it might be different still.
This appears to be due to a bad interaction between and associated type projections involving lifetimes. When we normalize the function signature during type-checking, we project to . We then convert back to the 'generic' region for , which is . However, this is a distinct early bound region, different from the in (changing the regions to not all be called in the example makes this clearer). This causes issues during , since we've essentially pulled a region out of thin air. This issue doesn't seem to come up for type parameters ( with lifetimes replaced with types). I'm not sure if this is because our handling of type parameters is correct for this kind of projection, or if we need a more complicated example to break things.
The ICE no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.

I got an internal compiler error at commit . I dont know how to minimize it. Relevant code is: If I remove the const field and directly put the array size like below, the ICE goes away and I get the expected compilation error that [u8; 68] is not . <details<summaryBacktrace:</summary</details<details<summaryVersion info</summary</details
The ICE also goes away if I change to
Ok. I minimized it to just: It ICEs on latest nightly:
triage: P-high, assiging to self, removing nomination label
Following example fails to compile: <details<summaryError</summary</detailsEven if I add , still issue: or <details<summaryError</summary</detailsBut this works:
Also just got this; no idea how to minimize it and the trace doesn't seem useful:-
If this is referring to the field , it's defined as where is defined inside the impl as .
Inlining resolves the error, ie changing buffer's definition to .
no longer happens with the latest nightly (note that the playground's nightly isn't the latest). That was removed by . Marked as E-needs-test.
Change:
define DEF_TEST_CRATE_RULES check-stage$(1)-T-$(2)-H-$(3)-$(4)-exec: $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)) <del> check-stage$(1)-T-$(2)-H-$(3)-$(4)-exec: $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)) </del> $$(call TEST_OK_FILE,$(1),$(2),$(3),$(4)):  $(3)/stage$(1)/test/$(4)test-$(2)$$(X_$(2)) @$$(call E, run: $$<)

Discussion:
Original title: "compiletest has implicit dependency on libnative" compiletest has implicit dependency on libnative When I tried to do , I get the following: says this is because, despite 's continued use of , there is an implicit attempt to link in unless one puts in a attribute into the crate attributes. I plan to try to fix this pronto. After fixing the above, I get: So there's another separate problem blocking from working.
Still working on this, there was a new problem that came up (run-pass-fulldeps needs libsyntax to have been rebuilt), so I've updated the description and the title to reflect the more general issue here.
Change:
rustc_span = { path = "../rustc_span" } rustc_symbol_mangling = { path = "../rustc_symbol_mangling" } rustc_target = { path = "../rustc_target" } <ins> rustc_trait_selection = { path = "../rustc_trait_selection" } </ins> rustc_type_ir = { path = "../rustc_type_ir" } serde_json = "1.0.59" smallvec = { version = "1.8.1", features = ["union", "may_dangle"] }

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
MirSource::Promoted(_, i) => write!(w, "{:?} in", i)? } <del> write!(w, " {}", tcx.node_path_str(src.item_id()))?; </del> <ins> item_path::with_forced_impl_filename_line(|| { // see notes on #41697 elsewhere write!(w, " {}", tcx.node_path_str(src.item_id())) })?; </ins> if let MirSource::Fn(_) = src { write!(w, "(")?;

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); if !self.is_recursive_obligation(obligated_types, &data.parent_code) { <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } } ObligationCauseCode::ImplDerivedObligation(ref data) => {

Discussion:
I would expect to error with "overflow evaluating the requirement", or compile without issue. Instead it segfaults. () Errors:
This segfault occurs since 1.45.0, 1.44.1 emits the expected error. It'd be great if we could bisect if possible.
18 out of backtrace frames: <details<summaryDetails</summary</detailsProbably not very useful.
I believe that we still have the bors artifacts, so it should be possible to use . ping cleanup
Error: Only Rust team members can ping teams. Please let know if you're having trouble with this bot.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-07 to nightly-2020-05-08 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
It's likely related -- cc
Does fix this issue?
Hm, I don't think so, let me confirm it. -- Confirmed with the master toolchain, it doesn't fix this.
I believe we need to wrap and the similar invocations further down with
Change:
.collect::<Vec<_>>(); let mut params = Vec::with_capacity(self.params.len()); <del> for p in self.params.iter().filter(|p| !is_impl_trait(p)) { </del> <ins> for p in self.params.iter().filter(|p| !is_impl_trait(p) && !is_elided_lifetime(p)) { </ins> let p = p.clean(cx); params.push(p); }

Discussion:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.
Change:
} impl<'gcc, 'tcx> DebugInfoMethods<'tcx> for CodegenCx<'gcc, 'tcx> { <del> fn create_vtable_metadata(&self, _ty: Ty<'tcx>, _vtable: Self::Value) { </del> <ins> fn create_vtable_metadata(&self, _ty: Ty<'tcx>, _trait_ref: Option<PolyExistentialTraitRef<'tcx>>, _vtable: Self::Value) { </ins> // TODO(antoyo) }

Discussion:
The following code from the manual fails with rustboot .
How embarrassing. Thanks for the report, I'll look into it.
Fix mem op= mem bug in (via not terribly good fix). Closed by .
Change:
<ins> // check-fail // run-rustfix enum FakeResult<T> { Ok(T) } fn main() { let _x = if true { FakeResult::Ok(FakeResult::Ok(())) } else { FakeResult::Ok(()) //~ERROR E0308 }; } </ins>

Discussion:
rustc version: rustc 1.65.0-nightly ( 2022-08-25) I have a very small reproducer for a weird fix advice from rustc when the two branches of an if had a type mismatch: This will produce the following output: Applying this fix obviously doesn't help:
label +A-diagnostics +T-compiler +D-invalid-suggestion
Change:
--> $DIR/missing-assoc-item.rs:6:12 | LL |     for<B> B::Item: Send, <del> |            ^^^^^^^ help: use the fully-qualified path: `<B as IntoIterator>::Item` </del> <ins> |            ^^^^^^^ | help: if there were a trait named `Example` with associated type `Item` implemented for `B`, you could use the fully-qualified path | LL |     for<B> <B as Example>::Item: Send, |            ~~~~~~~~~~~~~~~~~~~~ </ins> error: aborting due to previous error; 1 warning emitted

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
Regression in cc
Change:
}) } <del> fn classify_ret<'a, Ty, C>(cx: &C, ret: &mut ArgAbi<'a, Ty>, abi: ABI) </del> <ins> fn classify<'a, Ty, C>(cx: &C, arg: &mut ArgAbi<'a, Ty>, abi: ABI, is_ret: bool) </ins> where Ty: TyAbiInterface<'a, C> + Copy, C: HasDataLayout, { <del> if !ret.layout.is_sized() { </del> <ins> if arg.is_ignore() || !arg.layout.is_sized() { </ins> // Not touching this... return; } <del> if !ret.layout.is_aggregate() { ret.extend_integer_width_to(64); </del> <ins> if !arg.layout.is_aggregate() { arg.extend_integer_width_to(64); </ins> return; } // The ELFv1 ABI doesn't return aggregates in registers <del> if abi == ELFv1 { ret.make_indirect(); return; } if let Some(uniform) = is_homogeneous_aggregate(cx, ret, abi) { ret.cast_to(uniform); return; } let size = ret.layout.size; let bits = size.bits(); if bits <= 128 { let unit = if cx.data_layout().endian == Endian::Big { Reg { kind: RegKind::Integer, size } } else if bits <= 8 { Reg::i8() } else if bits <= 16 { Reg::i16() } else if bits <= 32 { Reg::i32() } else { Reg::i64() }; ret.cast_to(Uniform::new(unit, size)); return; } ret.make_indirect(); } fn classify_arg<'a, Ty, C>(cx: &C, arg: &mut ArgAbi<'a, Ty>, abi: ABI) where Ty: TyAbiInterface<'a, C> + Copy, C: HasDataLayout, { if !arg.layout.is_sized() { // Not touching this... return; } if !arg.layout.is_aggregate() { arg.extend_integer_width_to(64); </del> <ins> if is_ret && abi == ELFv1 { arg.make_indirect(); </ins> return; }

Discussion:
I tried this code: I expected to see this happen: test suite passing Instead, this happened: The return failure is: The pass failure is: : This occurs in every version since the test was . I see this with 1.79.0 and 1.80.0 as well as my 1.81.0 beta build (). I haven't dug in to all of the nitty-gritty yet, but I have a feeling may be potentially incorrect?
Indeed, if I remove those two lines, it passes the tests correctly: But I'm not sure why they are there and if this could possibly cause breakage elsewhere. I'd be happy to open a PR with this change for comment if that is the best way forward, or we can continue to discuss here.
Indeed, there is fallout - this test used to pass:
Reading over the ELF ABI specification and how LLVM and GCC implement this, arguments and return values should be treated the same. So, trying to duplicate the logic from in yielded me: and gave me: which is actually the first time I've ever seen Rust complete its test suite fully on a big endian PPC64/musl environment! Since the logic doesn't vary between endian in , I'm not sure why it should in . Unfortunately, I don't have any spare hardware to try and run little-endian, so I can't test if this change actually does the right thing on LE. I suppose since the original code had a BE case which was suspiciously similar to the first half of , I could do the code as another branch there. But that feels ugly, and I'd like to know if this simpler way would work on both endians before trying to shoehorn deeper nested branches.
Change:
<ins> //@ edition:2015 // test for ICE #121807 begin <= end (12 <= 11) when slicing 'Self::Assoc<'_>' // fixed by #122749 trait MemoryUnit { // ERROR: not all trait items implemented, missing: `read_word` extern "C" fn read_word(&mut self) -> u8; extern "C" fn read_dword(Self::Assoc<'_>) -> u16; //~^ WARN anonymous parameters are deprecated and will be removed in the next edition //~^^ WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! //~^^^ ERROR associated type `Assoc` not found for `Self` } struct ROM {} impl MemoryUnit for ROM { //~^ ERROR not all trait items implemented, missing: `read_word` extern "C" fn read_dword(&'s self) -> u16 { //~^ ERROR use of undeclared lifetime name `'s` //~^^ ERROR method `read_dword` has a `&self` declaration in the impl, but not in the trait let a16 = self.read_word() as u16; let b16 = self.read_word() as u16; (b16 << 8) | a16 } } pub fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/ena- 'index out of bounds: the len is 4 but the index is 4'', 'thread 'rustc' panicked at /rust/deps/ena- 'index out of bounds: the len is 4 but the index is 4'' File: --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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in cc
Wow we leak an infer var out of the rollback scope that declared it
WG-prioritization assigning priority (). label -I-prioritize +P-medium
probably fixed by

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'begin <= end (6 <= 5) when slicing '', 'thread 'rustc' panicked at 'begin <= end (6 <= 5) when slicing '' File: --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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Change:
report_object_safety_error, suggestions::NextTypeParamName, }; use rustc_trait_selection::traits::wf::object_region_bounds; <del> use rustc_trait_selection::traits::{self, astconv_object_safety_violations, ObligationCtxt}; </del> <ins> use rustc_trait_selection::traits::{ self, astconv_object_safety_violations, NormalizeExt, ObligationCtxt, }; use rustc_type_ir::fold::{TypeFoldable, TypeFolder, TypeSuperFoldable}; </ins> use smallvec::{smallvec, SmallVec}; use std::collections::BTreeSet;

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 --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim