jiebi/CodeConvo huggingface dataset:
Change:
"--compile-lib-path=", "--run-lib-path=", "--rustc-path=", <del> "--lldb-python=", "--docck-python=", </del> <ins> "--python=", </ins> "--jsondocck-path=", "--src-base=", "--build-base=",

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins>

Discussion:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?
Change:
} fn parse_desc(attrs: ~[ast::attribute]) -> Option<~str> { <del> match doc_meta(attrs) { Some(meta) => { attr::get_meta_item_value_str(meta) } None => None </del> <ins> let doc_strs = do doc_metas(attrs).filter_map |meta| { attr::get_meta_item_value_str(*meta) }; if doc_strs.is_empty() { None } else { Some(str::connect(doc_strs, "n")) </ins> } }

Discussion:
If document strings for rustdoc are written as a sequence of single line comments (i.e. ///) then rustdoc only uses the first line. The whole sequence should be joined to form a single attribute for further processing.
I would be happy to have a look at this (I guess maybe I caused the issue).
It seems like one way to fix this issue would be to have rustdoc concatenate all doc-attributes/doc-comments for an item and use the concatenated text as if it were from a single doc-attribute/comment. Currently rustdoc discards all but the first doc-attribute, and emits a warning that the others were discarded. However the warning is emitted using warn!(...) which means it doesn't actually display to the user unless they have turned on warn logging for rustdoc, which seems unlikely. Would this approach (concatenating all doc-comments) be ok?
Another approach would be to change the lexer so that it parses multiple adjacent lines that all start with /// as a single doc-comment.
Having rustdoc concatenate the attributes sounds good to me.
You're right, I ran rustdoc without warnings being logged. Are you referring to fn docmeta in That looks like it would be a sensible place to do the concatenation.
Yup. See the pull request - it makes multi-line comments work the same as comments (as a side effect of concatenating all kinds of doc-comment). Unfortunately multi-line comments seem a bit broken in general with rustdoc. In html output mode they are concatenated into a single line (I think due to some weirdness with pandoc).
Fixed by
Change:
<del> Subproject commit fa046d2e7f14cda09d14230cc8c772e1565e0757 </del> <ins> Subproject commit c0f39cfb466202a1dbe8368ca177848083dc34cb </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. 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! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
} fn ignore_edge(&mut self, bb: BasicBlock, target: BasicBlock) -> bool { <ins> let terminator = self.body[bb].terminator(); if terminator.unwind() == Some(&Some(target)) && terminator.successors().count() > 1 { return true; } </ins> // Don't traverse successors of recursive calls or false CFG edges. match self.body[bb].terminator().kind { TerminatorKind::Call { ref func, .. } => self.is_recursive_call(func), <del> TerminatorKind::FalseUnwind { unwind: Some(imaginary_target), .. } | TerminatorKind::FalseEdge { imaginary_target, .. } => imaginary_target == target, </del> <ins> TerminatorKind::FalseEdge { imaginary_target, .. } => imaginary_target == target, </ins> _ => false, } }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code which causes a stack overflow due to a recursive call of I mistakenly . I expected to see the warning. However, the compiler didn't complain it. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.43.0 showed the warning. (ref. ) The warning isn't shown on 1.44.0 or later, including the current stable 1.47.0. <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
I think this was caused by , but it looks like expected behavior: If diverges, the self-recursion never happens.
Though maybe the lint should assume that functions returning an inhabited type won't diverge (since otherwise they should be marked ). I can definitely see why people would write code like this, so linting on it makes sense.
I personally feel that we should lint for functions if they don't return an uninhabited type. Even if someone wants to exit recursion by unwinding I do feel that a lint is still appropriate here as it is really bad style imo.
Thanks for the quick response. Yeah, it'd be natural to expect a function whose return type is not to return eventually. Probably, we might want to have the following rules?: for self-recursion unless a function returning an uninhabited type is called in advance. a non-diverge function is called before a self-recursion, show a message like "if this diverges, please annotate it." in addition to the warning. 1 would help my case and 2 would help the case of . (2 is not necessary, though.)
Assigning as and removing .
Change:
| = note: this error originates in the macro `env` (in Nightly builds, run with -Z macro-backtrace for more info) <del> error: aborting due to 1 previous error </del> <ins> error: environment variable `NON_UNICODE_VAR` is not a valid Unicode string --> non_unicode_env.rs:3:13 | 3 |     let _ = option_env!("NON_UNICODE_VAR"); |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `option_env` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 2 previous errors </ins>

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .
Change:
/// in the given `OsString`. The string may reserve more space to speculatively avoid /// frequent reallocations. After calling `try_reserve`, capacity will be /// greater than or equal to `self.len() + additional` if it returns `Ok(())`. <del> /// Does nothing if capacity is already sufficient. </del> <ins> /// Does nothing if capacity is already sufficient. This method preserves /// the contents even if an error occurs. </ins> /// /// See the main `OsString` documentation information about encoding and capacity units. ///

Discussion:
Any methods of container types (12 in Rust 1,62.1, including duplicated ones in ), and maybe corresponding methods. - - - - ... and corresponding methods in . Documentations for describes "If the capacity overflows, or the allocator reports a failure, then an error is returned.". However, it does not give any guarantees about whether the content is preserved or not on that error. This guarantee (or absence of the guarantee) should be explicitly described.
At least for (and -based things like ) it's obvious to guarantee that, so we might as well. (Thank you, Rust, for insisting on move-is- so we don't have the "what if the move constructor panics" problems like C++.) I think it'll need to be to hashbrown before we can consider promising it for /, through -- there's no guarantee in <https://rust-
Modulo needing to add it in hashbrown, shall we see if we have consensus to say that failures preserve the current contents? 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] [ ] [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.
: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. This will be merged soon.
Please feel free to post a PR for this.
Created a PR for this.
Change:
} PatKind::Tuple(ref subpatterns, ddpos) => { <del> match self.tcx.tables().node_id_to_type(pat.id).sty { </del> <ins> let ty = self.tcx.tables().node_id_to_type(pat.id); match ty.sty { </ins> ty::TyTuple(ref tys) => { let subpatterns = subpatterns.iter()

Discussion:
My bad, there's a temporary that ended up in a discriminant. Minimal testcase: The can be fixed by pulling it out into a variable, .
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-99914.rs:9:27 | LL |     t.and_then(|t| -> _ { bar(t) }); |                           ^^^^^^ expected enum `Result`, found opaque type | note: while checking the return type of the `async fn` --> $DIR/issue-99914.rs:13:23 | LL | async fn bar(t: Okay) {} |                       ^ checked the `Output` of this `async fn`, found opaque type = note:     expected enum `Result<_, Error>` found opaque type `impl Future<Output = ()>` help: try wrapping the expression in `Ok` | LL |     t.and_then(|t| -> _ { Ok(bar(t)) }); |                           +++      + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. --This was in a closed source codebase I don't have time to minimize right now. It happened when I called (or something like that, don't exactly remember) on a value with type . Don't remember what T or E were :( <!-- 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
might be related to one of these ^^
Ugh, this is due to adding this  call -- something is calling this with a type that has region variables that no longer exist, probably from an or ... I can possibly try to reproduce, but this will be difficult to do without an MVCE.
can you try or is this a different issue?
This is a different issue. is a trait solver issue having to do with higher ranked type equality and the . This has to do with a region variable escaping out of a . Specifically it's this one:
Actually wait this is a type variable that's escaping. Ugh, probably due to opaque types :?
oh I forgot I saved this code I will try to trim it down to something I can post publicly
if you can, it would be incredibly useful here.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // check-pass #[repr(transparent)] struct NonNullRawComPtr<T: ComInterface> { inner: std::ptr::NonNull<<T as ComInterface>::VTable>, } trait ComInterface { type VTable; } extern "C" fn invoke<T: ComInterface>(_: Option<NonNullRawComPtr<T>>) {} fn main() {} </ins>

Discussion:
On the latest nightly (2020-06-25), a small usage of the crate causes an ICE when trying to compile even a small example. I confirmed that the past week of nightly releases compile fine before the latest. On the latest stable (1.44.1) this compiles just fine as expected. <!-- 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
Let’s try to find an MCVE. I’d also like to find the culprit PR, which shouldn’t take too long since we know in which nightly this regressed. 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
Just tried this out locally as well and can confirm the ICE happens.. time to dig in ..
ping windows
Hey Windows Group! This bug has been identified as a good "Windows 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
Similar ICE <details<summaryICE / Backtrace</summary<p</p</details
Prioritized this one as as per
This ICE went away between nightly-2020-06-28 and nightly-2020-06-29. Bisecting further now.
searched nightlies: from nightly-2020-06-28 to nightly-2020-06-29 regressed nightly: nightly-2020-06-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Minified, With the message,
's MCVE shows that this problem is not windows-specific. Updating labels accordingly.

Also, it looks to me like this MCVE still reproduces on the current nightly. (So something must have been off with my earlier bisection that claimed it was fixed. The original problem has been tricky for me to consistently reproduce.)
On the plus side, I was able to run cargo-bisect-rustc on 's MCVE (to identify the point where it regressed), and got this result: searched nightlies: from nightly-2020-06-22 to nightly-2020-07-14 regressed nightly: nightly-2020-06-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Culprit is likely ? cc
Keeping at P-critical based on conversation at: https://zulip-
reopening; the next beta was cut before this landed in master, so this ended up being a regression-from-stable-to-beta
however, I also think the bug is under control now that the PR has landed on nightly. Reprioritizing as P-high.
The fix was backported, closing.
Change:
<ins> error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds --> $DIR/issue-87258_a.rs:19:21 | LL |     fn foo<'a>() -> Self::FooFuture<'a> { |                     ^^^^^^^^^^^^^^^^^^^ | = note: hidden type `Struct<'_>` captures lifetime '_#7r error: aborting due to previous error For more information about this error, try `rustc --explain E0700`. </ins>

Discussion:
: (Also ) <details<summary<strongBacktrace</strong</summary<p</p</details
Issue might be related (or this may be a duplicate of it).
This seems to be caused by Re-inserting gets rid of the ICE. What was the rationale for deleting that function?
It was replacing inference lifetimes with concrete ones (but wrong ones, as it was using lifetimes from a completely different item). This avoided certain ICEs and was even correct by accident for the example in the doc comment, but it was just papering over the ICEs causing other examples (where the impl trait is outside the current impl block) to fail. I am looking into this new ICE now
I am getting locally before the ICE, so likely the ICE just hides actual errors. Should still fix that of course, but needs more looking into it
I think you need to use 2018 or 2021 edition.
minimized and edition-free: The problem is that typeck runs some of old borrowck/regionck and that just can't handle GAT and associated TAIT being used together. While worked in this specific case, that function won't work if the TAIT were declared outside the impl block and only used, so the following would just hit a different ICE, even though it should be equivalent (except that the defining use scope is the surrounding module instead of just the impl block).
So... turns out this works just fine with nll... I'd say we just wait for that, nll is only blocked on diagnostics, and those are actively being worked on:
I've found this does work if adding a bound on the TAIT: . It seems to me that should be required, so accepting code without it was actually a bug? Also, how does this work with NLL? I add and it still ICEs. (see the playground). Is there anything else needed for enabling NLL?
It seems the linked example on the playground does not ICE on the 2021-08-03 nightly.
that's with the fixed . Without it it ICEs, both with and without NLL
Hum, indeed, the 2 minimized examples Oli mentioned in do ICE with or without .
oof, not sure what I tested here -.- I'll investigate again. But yea, we can just error out instead of ICEing.
This, and no longer ICE since
GATs issue triage: not blocking. Fixed; needs test.
Change:
<del> // Regression test for various ICEs inspired by // https://github.com/rust-lang/rust/issues/83921#issuecomment-814640734 // compile-flags: -Zdeduplicate-diagnostics=yes #[repr(packed())] //~^ ERROR: incorrect `repr(packed)` attribute format struct S1; #[repr(align)] //~^ ERROR: invalid `repr(align)` attribute struct S2; #[repr(align(2, 4))] //~^ ERROR: incorrect `repr(align)` attribute format struct S3; #[repr(align())] //~^ ERROR: incorrect `repr(align)` attribute format struct S4; #[repr(i8())] //~^ ERROR: invalid representation hint enum E1 { A, B } #[repr(u32(42))] //~^ ERROR: invalid representation hint enum E2 { A, B } #[repr(i64 = 2)] //~^ ERROR: invalid representation hint enum E3 { A, B } fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' 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: --
Regression in nightly-2023-08-26
Change:
self.drain_filter(|v| !f(v)); } <del> /// Moves all elements from `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all elements from `other` into `self`, leaving `other` empty. </ins> /// /// # Examples ///

Discussion:
See the documentation for here and for here: In both cases, the documentation refers to the object the method is called for, not the type, so it should be using the lower case . (And maybe should be in backticks here?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-docs +T-libs +E-easy
claim