jiebi/CodeConvo huggingface dataset:
Change:
if no_accessible_remaining_fields { self.report_no_accessible_fields(adt_ty, span); } else { <del> self.report_missing_field(adt_ty, span, remaining_fields); </del> <ins> self.report_missing_fields(adt_ty, span, remaining_fields); </ins> } }

Discussion:
Test example (): Only in the top level should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the field as private (even though it inherits from the ). The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of , and unmodified since. It's using which seems correct, but it's possible fields are incapable of giving the right result, if they don't track the 's own privacy (and they only know they inherit it, whatever it is). cc
I would also suspect
I ran into this too, but I couldn't make a repro. Thanks eddyb!
P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!
searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15 regressed nightly: nightly-2020-09-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Seems very likely that this is due to , as eddyb said. EDIT: Though, as jyn514 suggested, the underlying bug could be , which was then surfaced in .
Update: I've been reading the source code and print-debugging and I think the issue was not introduced in either of those two PRs, but rather that they surfaced a pre-existing issue.
Well, it took a while, but I think I fixed it!
Does this necessitate a 1.48.1 release or shall I wait for 1.49?
it will be in 1.50 unless backported:
Ok. Thank you for the quick reply.
Change:
// xfail-fast <del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
The bots are currently failing like so I bisected to , which changes how works.
Closing since I'm almost certain that test is either gone, or passes.
This continues to be a source of breakage on incoming. Right now the failure is in rpass/auto-encode
run-pass/auto-encode is xfailed now
my branch contains a reduced test case under run-pass/issue-6122
incoming has been poofed, so I'm not sure what the status of this is. Bors has been churning away and the tree is green, so does the problem still arise?
The test passes locally for me with some updating. Pushed it to try, will see how it falls.
Change:
| sym::deny | sym::forbid | sym::cfg <ins> | sym::cfg_attr </ins> // need to be fixed | sym::cfi_encoding // FIXME(cfi_encoding) | sym::may_dangle // FIXME(dropck_eyepatch)

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: builtin attribute "cfgattr" not handled by ', 'error: internal compiler error: builtin attribute "cfgattr" not handled by ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
Change:
<ins> error[E0515]: cannot return value referencing local variable `s` --> $DIR/issue-67765-async-diagnostic.rs:13:11 | LL |     let b = &s[..]; |              - `s` is borrowed here LL | LL |     Err(b)?; |           ^ returns a value referencing data owned by the current function error: aborting due to previous error For more information about this error, try `rustc --explain E0515`. </ins>

Discussion:
This code: Returns this error: Which is very unhelpful; it should at least in some way point to the line with the . This happens on rustc 1.40.0 ( 2019-12-16). For reference, this is the equivalent non-async error message (much more helpful): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Marking as focus, since improving diagnostics are important to the wg.
Change:
None => { // We didn't find any issues, so we need to push the algorithm forward // First, eliminate any arguments that currently satisfy their inputs <del> for (inp, arg) in self.eliminate_satisfied() { </del> <ins> let eliminated = self.eliminate_satisfied(); assert!(!eliminated.is_empty(), "didn't eliminated any indice in this round"); for (inp, arg) in eliminated { </ins> matched_inputs[arg] = Some(inp); } }

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. --I tried this code: I expected to see this happen: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
error[E0308]: try expression alternatives have incompatible types <del> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:20:5 </del> <ins> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:18:5 </ins> | LL |     missing_discourses()? <del> |     ^^^^^^^^^^^^^^^^^^^^^ |     | |     expected enum `std::result::Result`, found isize |     help: try wrapping with a success variant: `Ok(missing_discourses()?)` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found isize </ins> | = note: expected type `std::result::Result<isize, ()>` found type `isize`

Discussion:
Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)
Change:
} impl Disambiguator { <del> /// The text that should be displayed when the path is rendered as HTML. /// /// NOTE: `path` is not the original link given by the user, but a name suitable for passing to `resolve`. fn display_for(&self, path: &str) -> String { match self { // FIXME: this will have different output if the user had `m!()` originally. Self::Kind(DefKind::Macro(MacroKind::Bang)) => format!("{}!", path), Self::Kind(DefKind::Fn) => format!("{}()", path), _ => path.to_owned(), } } /// Given a link, parse and return `(disambiguator, path_str)`. </del> <ins> /// Given a link, parse and return `(disambiguator, path_str, link_text)`. </ins> /// /// This returns `Ok(Some(...))` if a disambiguator was found, /// `Ok(None)` if no disambiguator was found, or `Err(...)` /// if there was a problem with the disambiguator. <del> fn from_str(link: &str) -> Result<Option<(Self, &str)>, (String, Range<usize>)> { </del> <ins> fn from_str(link: &str) -> Result<Option<(Self, &str, &str)>, (String, Range<usize>)> { </ins> use Disambiguator::{Kind, Namespace as NS, Primitive}; if let Some(idx) = link.find('@') {

Discussion:
Consider this code: I'm not sure if this is a deliberate decision or not. If it is, what's the rationale for not accepting and ? cc
It isn't valid markdown syntax.
Well, might be. But [] definitely is not.
seems to work fine (it renders as and the link is correct). But maybe you're saying that we shouldn't accept because it wouldn't be valid markdown? Is it worth implementing?
hmm, it might be valid in that position, but it's not valid as a link reference: But I guess there's no reason for rustdoc to explicitly reject it. I would be ok with it, may have opinions.
I'm okay with it. I'm mostly wary about characters that are common in URLs, curly braces are not.
Oh, the reason why works is because the rules for inline links are more relaxed: vs So instead do you think rustdoc should parse ?

Consider this code: In the generated docs, the link on the page appears as , with the correct link, but without the parentheses.
Sorry, I stole this from you :smile:
That's okay! Thanks for fixing this :)
Change:
builder: &Builder<'_>, target: TargetSelection, ) -> Result<LlvmResult, Meta> { <ins> // If we have llvm submodule initialized already, sync it. builder.update_existing_submodule(&Path::new("src").join("llvm-project")); </ins> builder.config.maybe_download_ci_llvm(); // If we're using a custom LLVM bail out here, but we can only use a

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. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
"rustc_tools_util 0.2.0", "semver", "serde", <del> "tester 0.7.0", </del> <ins> "tester", </ins> ] [[package]]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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.
triage: P-medium, removing nomination label.
Change:
Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/97550 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/102790 </ins>

Discussion:
In particular, this means you have to rebuild llvm for the host when cross-compiling. I tried this code: . I expected to see this happen: The compiler builds successfully. Instead, this happened: I think there's a secondary bug which is that x.py hard-codes instead of . But that seems easier to fix. <!-- 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<summaryBacktrace</summary<p</p</details
Mentoring instructions: where in it generates the component (I think I might be in ) llvm-tblgen to the binaries that are copied a PR and ask someone to run , which will generate CI artifacts. the merge commit from the build locally and confirm that works successfully (or if you're not on Linux, some other platform that's binary compatible).
label: +E-mentor
Make sure to only copy it if it exists. It doesn't get build if the llvm backend isn't enabled.
It looks like unconditionally copies llvm binaries right now, so I think should be no different.
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn is_copy<T: ::std::marker<i32>::Copy>() {} //~^ ERROR type parameters are not allowed on this type [E0109] fn main() {} </ins>

Discussion:
The way we currently check type parameters is inconsistent and error prone. The code below compiles and it shouldn't. The phase currently ignores these checks and leaves them up to , and , which as demonstrated by bugs like this one and makes this check unsound.
Triage: this still compiles.
Triage: Still compiles.
Marking as E-needstest.
Change:
pub use iter::IntoIter; /// Converts a reference to `T` into a reference to an array of length 1 (without copying). <del> #[unstable(feature = "array_from_ref", issue = "77101")] </del> <ins> #[stable(feature = "array_from_ref", since = "1.53.0")] </ins> pub fn from_ref<T>(s: &T) -> &[T; 1] { // SAFETY: Converting `&T` to `&[T; 1]` is sound. unsafe { &*(s as *const T).cast::<[T; 1]>() } } /// Converts a mutable reference to `T` into a mutable reference to an array of length 1 (without copying). <del> #[unstable(feature = "array_from_ref", issue = "77101")] </del> <ins> #[stable(feature = "array_from_ref", since = "1.53.0")] </ins> pub fn from_mut<T>(s: &mut T) -> &mut [T; 1] { // SAFETY: Converting `&mut T` to `&mut [T; 1]` is sound. unsafe { &mut *(s as *mut T).cast::<[T; 1]>() }

Discussion:
Tracking issue for which adds the following methods [x] Implementation: [ ] FCP [ ] Stabilization PR
Nvm, it's a typo in the issue description, the actual method is named . What is blocking stabilization, it seems like there aren't any open questions/controversies. Shall I make a stabilization PR?
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.
: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.
Has anyone proposed to stabilize these? Could I just open a PR to start that? :)
I've proposed. In fact, they were already stabilized :)
Since and has been stablized, could we now add , and to libcore? These impls should be easy to implement (just one-liners) and ergonomic to use.
Feel free to create a pull request! I would imagine it would be accepted.
Adding could conflict with downstream . Similarly, since and are "fundamental" and behave like their pointee for coherence purposes, downstream impls of etc are also currently allowed, such that adding would also conflict. Adding another candidate for also was pointed out as possibly being .
Change:
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types --> $DIR/coherence.rs:14:1 | <del> LL | impl<T> foreign_crate::ForeignTrait for AliasOfForeignType<T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--------------------- | |                                       | | |                                       `AliasOfForeignType<T>` is not defined in the current crate </del> <ins> LL | impl foreign_crate::ForeignTrait for AliasOfForeignType<()> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------------- | |                                    | | |                                    `AliasOfForeignType<()>` is not defined in the current crate </ins> | impl doesn't use only types from inside the current crate | = note: define and implement a trait or new type instead

Discussion:
The following UB compiles: The impl is invalid because the lifetime parameter appears unconstrained in the impl header. It should be rejected for the same reason that projection types doesn't constraint impl generics: label C-bug T-types I-unsound requires-nightly F-typealiasimpl_trait
Change:
<del> { "type": "suite", "event": "started", "test_count": "4" } </del> <ins> { "type": "suite", "event": "started", "test_count": 4 } </ins> { "type": "test", "event": "started", "name": "a" } { "type": "test", "name": "a", "event": "ok" } { "type": "test", "event": "started", "name": "b" }

Discussion:
The output of a test suite starting when using the json formatter represents "test_count" as a json string, like so: I would expect it to be a number like this:
It also seems like "filtered_out" on run finish is also unexectedly a string.
Change:
<ins> error[E0277]: the trait bound `&'a T: std::marker::Unsize<&'a U>` is not satisfied --> $DIR/issue-71036.rs:11:1 | LL | impl<'a, T: ?Sized + Unsize<U>, U: ?Sized> DispatchFromDyn<Foo<'a, U>> for Foo<'a, T> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::marker::Unsize<&'a U>` is not implemented for `&'a T` | = note: all implementations of `Unsize` are provided automatically by the compiler, see <https://doc.rust-lang.org/stable/std/marker/trait.Unsize.html> for more information = note: required because of the requirements on the impl of `std::ops::DispatchFromDyn<&'a &'a U>` for `&'a &'a T` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
I was playing with while I encountered a The simplest example I have producing the bug is Here is . It works if I remove the struct and put the directly in . The complete backtrace is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimised ()
claim
Change:
Some(ItemLink { link: ori_link.link.clone(), link_text: link_text.clone(), <del> did: res.def_id(self.cx.tcx), </del> <ins> page_id: res.def_id(self.cx.tcx), </ins> fragment, }) }

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. --field contains wrong IDs for some kind of items. Items for which no independent HTML is generated (link target URL is ) appear to have incorrect IDs. I tried this code: I expected to see this happen: contains the IDs of link targets Instead, this happened: contains the ID of the items containing the link targets <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +A-rustdoc-json +T-rustdoc +A-intra-doc-links
claim
Change:
unsafe { cmath::cbrt(self) } } <del> /// Calculates the length of the hypotenuse of a right-angle triangle given /// legs of length `x` and `y`. </del> <ins> /// Compute the distance between the origin and a point (`x`, `y`) on the /// Euclidean plane. Equivalently, compute the length of the hypotenuse of a /// right-angle triangle with other sides having length `x.abs()` and /// `y.abs()`. </ins> /// /// # Examples ///

Discussion:
The documentation for the / function reads and gives this example (and the analogous example for ): Since lengths are always positive, it's unclear what this function does for negative values. My expectation is that it gives the hypotenuse of the right triangle whose leg lengths are the absolute values of and , but I had to look up to be sure, which reads <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This looks relatively simple, and I'd like to contribute. Could I take this issue?
claim
Change:
[rust] # This greatly increases the speed of rebuilds, especially when there are only minor changes. However, it makes the initial build slightly slower. incremental = true <ins> # Make the compiler and standard library faster to build, at the expense of a ~20% runtime slowdown. lto = "off" </ins> [llvm] # Will download LLVM from CI if available on your platform.

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
<ins> // In #88097, the compiler attempted to coerce a closure type to itself via // a function pointer, which caused an unnecessary error. Check that this // behavior has been fixed. // check-pass fn peculiar() -> impl Fn(u8) -> u8 { return |x| x + 1 } fn peculiar2() -> impl Fn(u8) -> u8 { return |x| x + 1; } fn peculiar3() -> impl Fn(u8) -> u8 { let f = |x| x + 1; return f } fn peculiar4() -> impl Fn(u8) -> u8 { let f = |x| x + 1; f } fn peculiar5() -> impl Fn(u8) -> u8 { let f = |x| x + 1; let g = |x| x + 2; return if true { f } else { g } } fn main() {} </ins>

Discussion:
Given : The current output is: Ideally the code would compile successfully, but if that is infeasible, it would be nice if the diagnostic contained a hint to remove the . (It's rather head-scratching that the closure is being converted to a fn pointer even though the return type has also been resolved to be the closure type.) The is entirely unnecessary here, but I imagine a beginner might include it unthinkingly (as I did) and not be able to even guess that the has anything to do with the type error. The results are the same on stable 1.54.0, beta, and nightly. If I modify the closure to not be coercible to a function pointer by capturing a variable, then the code compiles without error or relevant warning: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +A-closures +A-inference
Interestingly, this compiles (note the semicolon): claim