jiebi/CodeConvo huggingface dataset:
Change:
} } <del> /// A common error is to add an extra semicolon: /// /// ```compile_fail,E0308 /// fn foo() -> usize { ///     22; /// } /// ``` /// /// This routine checks if the final statement in a block is an /// expression with an explicit semicolon whose type is compatible /// with `expected_ty`. If so, it suggests removing the semicolon. pub(crate) fn consider_removing_semicolon( &self, blk: &'tcx hir::Block<'tcx>, expected_ty: Ty<'tcx>, err: &mut Diag<'_>, ) -> bool { if let Some((span_semi, boxed)) = self.err_ctxt().could_remove_semicolon(blk, expected_ty) { if let StatementAsExpression::NeedsBoxing = boxed { err.span_suggestion_verbose( span_semi, "consider removing this semicolon and boxing the expression", "", Applicability::HasPlaceholders, ); } else { err.span_suggestion_short( span_semi, "remove this semicolon to return this value", "", Applicability::MachineApplicable, ); } true } else { false } } </del> pub(crate) fn is_field_suggestable( &self, field: &ty::FieldDef,

Discussion:
The code below has superfluous semicolons in the branches of the if expression: The error message that results is: This can be confusing to beginners, who may not understand unit type. However, since the expressions and can be shown to have no side effects, the code (as is) can't be what the user intended. Could the compiler produce a more targeted error message that mentions the superfluous semicolon? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-compiler A-diagnostics D-newcomer-roadblock D-terse
claim
Thinking more about this, I don't think we should extend the "remove semicolon to make tail expression" suggestion to cover this case, since we don't know the expected type of at the point at which the suggestion would be made. For example, we don't make the suggestion to change to here: But that's just a guess based on my limited knowledge of type mismatch suggestions. Maybe someone else could weigh in?
Change:
}; use rustc_span::def_id::DefId; <ins> #[derive(Copy, Clone, Debug)] enum EdgeKind { Unwind, Normal, } </ins> pub struct Validator { /// Describes at which point in the pipeline this validation is happening. pub when: String,

Discussion:
Blocks that are part of unwinding code always need to marked as . This seems like an easy thing to check in the validation pass. I believe this would have caught a bug in the generator transform (a pretty long time ago). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Good point! Moreover, cleanup block terminators should also only jump to cleanup blocks, and other terminators should only jump to non-cleanup blocks. Basically, unwind edges must be the only ones that cross the "cleanup to non-cleanup" boundary. (Miri is already checking this.)
claim
Change:
<ins> // check-pass // Checks that we can infer a closure signature even if the `FnOnce` bound is // a supertrait of the obligations we have currently registered for the Ty var. pub trait Receive<T, E>: FnOnce(Result<T, E>) { fn receive(self, res: Result<T, E>); } impl<T, E, F: FnOnce(Result<T, E>)> Receive<T, E> for F { fn receive(self, res: Result<T, E>) { self(res) } } pub trait Async<T, E> { fn receive<F: Receive<T, E>>(self, f: F); } impl<T, E> Async<T, E> for Result<T, E> { fn receive<F: Receive<T, E>>(self, f: F) { f(self) } } pub fn main() { Ok::<u32, ()>(123).receive(|res| { res.unwrap(); }); } </ins>

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
self } <ins> /// Clear any existing suggestions. pub fn clear_suggestions(&mut self) -> &mut Self { if let Ok(suggestions) = &mut self.suggestions { suggestions.clear(); } self } </ins> /// Helper for pushing to `self.suggestions`, if available (not disable). fn push_suggestion(&mut self, suggestion: CodeSuggestion) { if let Ok(suggestions) = &mut self.suggestions {

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
<ins> error: use of deprecated `try` macro --> $DIR/try-macro-suggestion.rs:3:8 | LL |     Ok(try!()); |        ^^^^^^ | = note: in the 2018 edition `try` is a reserved keyword, and the `try!()` macro is deprecated help: you can still access the deprecated `try!()` macro using the "raw identifier" syntax | LL |     Ok(r#try!()); |        ^^ error: use of deprecated `try` macro --> $DIR/try-macro-suggestion.rs:4:8 | LL |     Ok(try!(Ok(()))) |        ^^^^^^^^^^^^ | = note: in the 2018 edition `try` is a reserved keyword, and the `try!()` macro is deprecated help: you can use the `?` operator instead | LL |     Ok(Ok(())?) |       --     ^ help: alternatively, you can still access the deprecated `try!()` macro using the "raw identifier" syntax | LL |     Ok(r#try!(Ok(()))) |        ^^ error: aborting due to 2 previous errors </ins>

Discussion:
Old documentation and blogposts will never be updated to not talk about the macro. is It should provide structured suggestions to either use or : This request is similar in spirit to and feels like a subset of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Would it be fine if I modified and check if the keyword is used, or is there another way to tackle this issue
Change:
<ins> error[E0658]: generic associated types are unstable --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error: type-generic associated types are not yet implemented --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
This code (): results in an ICE:
Isn't that a close cousin of
Not really, this is an associated function rather than an inner function.
I'm investigating this. Still repros on . With : <details<summaryBacktrace </summary</details
After investigating, the current ICE is caused by the () inside of not being able to locate the generic parameter it is trying to substitute for. The code at fault is: Which should try and find based on the (), but the current code only handles the situation like .
No longer ICEs, I believe down to Looking at the backtrace on nightly-2019-12-05 this seems related to and also
This no longer ICEs OR errors, at least for me. What backtrace do you mean? AFAICT this can be closed.
Whoops, wrote the wrong date down. I meant the nightly when it did ICE, it was 2019-12-01 or thereabouts. Yeah it can be closed once there's a regression test
Change:
/// The difference between `unimplemented!` and [`todo!`] is that while `todo!` /// conveys an intent of implementing the functionality later and the message is "not yet /// implemented", `unimplemented!` makes no such claims. Its message is "not implemented". <del> /// Also some IDEs will mark `todo!`s. </del> <ins> /// /// Also, some IDEs will mark `todo!`s. </ins> /// /// # Panics ///

Discussion:
The documentation of the macro currently does not mention at all that it also accepts optional format arguments, for example: Other macros like at least have the following sentence under "Panics": So maybe it would be good to do the following? [ ] Update the "Panics" section to be similar to [ ] Extend / adjust example to also show usage of custom message <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Any ? I mostly drew from the docs for , and I also took the liberty of cleaning up some of the formatting/typography.
Thanks! To me this looks good, but I don't know what the maintainers think.
Change:
<ins> error[E0599]: no method named `to_string` found for type `*const u8` in the current scope --> $DIR/issue-21596.rs:4:22 | LL |     println!("{}", z.to_string()); |                      ^^^^^^^^^ | = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref = note: the method `to_string` exists but the following trait bounds were not satisfied: `*const u8 : std::string::ToString` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
When trying to call a method on a raw pointer Rust compiler says there's no such method. It would be better to say that there is such method, but the pointer has to be explicitly dereferenced first. This is technically correct, but unexpected and help hint for this error suggests wrong solution. I've read this message as "yada yada no such method", so I went to check whether I've spelled the method correctly, whether I've put the method in the appropriate block, etc. — all completely irrelevant to this error. I'd find something like that more helpful:
, though. The best we could do here is to add some logic in trait suggestion mechanism to check whether traits for dereferenced values exist. Something along the lines of Too many help messages will overwhelm messages that actually matter, though.
Triage: no change
Triage: the error message has improved /
To suggest it would have to suggest , which is taking the suggestions a bit far. We could add a note though.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // ignore-tidy-linelength // revisions: ast mir //[mir]compile-flags: -Z borrowck=mir </ins> fn inside_closure(x: &mut i32) { } <del> fn outside_closure(x: &mut i32) { </del> <ins> fn outside_closure_1(x: &mut i32) { } fn outside_closure_2(x: &i32) { </ins> } fn foo(a: &mut i32) { let bar = || { inside_closure(a) }; <del> outside_closure(a); //~ ERROR E0501 </del> <ins> outside_closure_1(a); //[ast]~ ERROR cannot borrow `*a` as mutable because previous closure requires unique access //[mir]~^ ERROR cannot borrow `*a` as mutable because previous closure requires unique access outside_closure_2(a); //[ast]~ ERROR cannot borrow `*a` as immutable because previous closure requires unique access //[mir]~^ ERROR cannot borrow `*a` as immutable because previous closure requires unique access </ins> } fn main() {

Discussion:
When compiling the test E0501, I get the following result: The message "cannot borrow it as because previous closure requires unique access" looks wrong - I think the arguments to got mixed up a bit.
I am working on this.
Change:
unsafe { llvm::LLVMDIBuilderFinalize(DIB(cx)); llvm::LLVMDIBuilderDispose(DIB(cx)); <ins> // Debuginfo generation in LLVM by default uses a higher // version of dwarf than OS X currently understands. We can // instruct LLVM to emit an older version of dwarf, however, // for OS X to understand. For more info see #11352 // This can be overridden using --llvm-opts -dwarf-version,N. if cx.sess.targ_cfg.os == abi::OsMacos { "Dwarf Version".with_c_str( |s| llvm::LLVMRustAddModuleFlag(cx.llmod, s, 2)); } // Prevent bitcode readers from deleting the debug info. "Debug Info Version".with_c_str( |s| llvm::LLVMRustAddModuleFlag(cx.llmod, s, llvm::LLVMRustDebugMetadataVersion)); </ins> }; }

Discussion:
Here's a recent session of mine Even if I continue into my own function (actually the symbol ), I'm not getting any source level debugging. Is there an extra option that I should be passing or should this be "just working"? I compiled a C executable with and I got nice debug-info without doing anything extra in lldb. cc
This is a known issue with the Servo team, fwiw.
Does clang give you usable debug symbols?
I do indeed get nice debugging with clang:
Could you dump the IR from clang and rustc for similar programs?
I'd also be interested in seeing if clang produces dSYM bundles and whether there are any observable differences between them and the ones that rustc produces. Relevant literature at .
This has the two IR outputs:
Clang: rustc: That's some strong difference there.
I spent a while tracking this down due to a red herring, but the actual issue is simple: the DWARF version is too high. As of OS X 10.9, 'dwarfdump' and 'dsymutil', the latter of which is required to aggregate DWARF info from .o files into the final executable, appear to ignore DWARF information with version 3. Rust uses LLVM's default of DWARF 4. clang defaults to DWARF 2 on OS X; in fact, the version of clang distributed with Xcode (but not the version I have installed through MacPorts? too tired to investigate this properly) seems to ignore -gdwarf-3 and above, so probably better to go with 2 than 3. Workaround: . I believe the correct way to solve this is for rustc to set the LLVM module flag "Dwarf Version", as clang does. It should also set "Debug Info Version", which, as far as I can tell, causes a separate issue where anything reading bitcode files using a new version of LLVM (e.g. the versions of llvm-dis or llc compiled by rust) will magically discard all the debug metadata.
you are my new favorite person in the world, thank you for figuring this out!!! I would be more than ok accepting a patch to pass these arguments by default! Pull requests are always welcome :)
Ship it, shipt it! :cactus:
This is a great find indeed!

For anyone interested, here is another source of information on DWARF on Mac OS X: The DWARF standard says that namespaces are not supported yet in version 2. I'd be interested in what the consequences of this are. Other than that I don't think we use anything that needs a newer version than 2. I'd be happy to turn this information into a fix and a pull request but I don't have a Mac to test it (yet). Thanks again :+1:
cc me
Change:
/// /// [`reserve_exact`]: ../ffi/struct.OsString.html#method.reserve_exact /// [`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_exact(&mut self, additional: usize) { self.inner.reserve_exact(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:
use crate::ffi::CStr; <ins> use crate::ffi::CString; </ins> use crate::io; use crate::num::NonZero; use crate::sys::unsupported;

Discussion:
Compilation of any code using the atomics feature flag for the wasm target fails when building the std library due to the following error: I tried this code: With these flags enabled I expected to see this happen: Compilation succesful Instead, this happened: : <details<summaryBacktrace</summary<pBacktrace doesn't seem to add useful information. </p</details
While playing around locally, adding this, in fixes the compiler error, not sure if there are undesired side effects.
That looks great! Would you be willing to submit a PR?
Definitely!
Change:
def.destructor(tcx); // force the destructor to be evaluated if vs.is_empty() { <del> if let Some(attr) = tcx.get_attr(def_id.to_def_id(), sym::repr) { </del> <ins> if let Some(attr) = tcx.get_attrs(def_id.to_def_id(), sym::repr).next() { </ins> struct_span_err!( tcx.sess, attr.span,

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
use crate::autoderef::Autoderef; use crate::infer::InferCtxt; <del> use crate::traits::normalize_projection_type; </del> <ins> use crate::traits::normalize_to; </ins> use rustc_data_structures::fx::FxHashSet; use rustc_data_structures::stack::ensure_sufficient_stack;

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: 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. --
Huh, looks like this is a case where doesn't kick in for some reason.
Ah, it's that the return type of an async function like this has . I don't know enough about rustc's typechecking to know whether this can be resolved haha.
It doesn't seem like the problem that caused is a thing anymore? I can remove the condition and it doesn't ICE on the example given in that issue.
do you know if stuff has changed such that is no longer necessary?
I actually have a PR almost up that does just exactly that, though if you want to put one up instead then feel free.
I'm pretty sure fixes this underlying issue. This method could use some additional cleanup as well.
Change:
] [[package]] <ins> name = "crossbeam" version = "0.8.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "4ae5588f6b3c3cb05239e90bd110f257254aecd01e4635400391aeae07497845" dependencies = [ "cfg-if 1.0.0", "crossbeam-channel", "crossbeam-deque", "crossbeam-epoch", "crossbeam-queue", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-channel" version = "0.5.4" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.