jiebi/CodeConvo huggingface dataset:
Change:
use crate::resolve_imports::{ImportDirective, ImportDirectiveSubclass, ImportResolver}; use crate::{path_names_to_string, KNOWN_TOOLS}; <del> use crate::{CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </del> <ins> use crate::{BindingError, CrateLint, LegacyScope, Module, ModuleOrUniformRoot}; </ins> use crate::{PathResult, ParentScope, ResolutionError, Resolver, Scope, ScopeSet, Segment}; type Res = def::Res<ast::NodeId>;

Discussion:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.

sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.
Change:
run: src/ci/scripts/verify-line-endings.sh <<: *step <ins> - name: ensure backported commits are in upstream branches run: src/ci/scripts/verify-backported-commits.sh <<: *step </ins> - name: run the build run: src/ci/scripts/run-build-from-ci.sh env:

Discussion:
The 1.45.1 release is primarily being made because of the accidental omission of a rustfmt backport from the 1.45 beta branch after it landed in 1.44.1. The release team discussed this today, and we'd like to implement some automation to try and prevent this in the future at relatively low cost. The plan is to only allow landing commits in beta / stable branches if (or similar, but that seems like the right thing) indicates they've already landed in the preceding branches (beta and master for stable, just master for beta). We will also want an explicit set of commits that are just allowed. This will slightly increase the work needed during beta backports, as this list will need updating if there are any merge conflicts at least -- but since backports are rare and usually rollups, this shouldn't be much of a problem hopefully. We would be interested in seeing someone implement this functionality! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
type_alias! { "c_uchar.md", c_uchar = u8, NonZero_c_uchar = NonZeroU8; } type_alias! { "c_short.md", c_short = i16, NonZero_c_short = NonZeroI16; } type_alias! { "c_ushort.md", c_ushort = u16, NonZero_c_ushort = NonZeroU16; } <ins> #[cfg(any(target_arch = "avr", target_arch = "msp430"))] type_alias! { "c_int.md", c_int = i16, NonZero_c_int = NonZeroI16; } #[cfg(not(any(target_arch = "avr", target_arch = "msp430")))] </ins> type_alias! { "c_int.md", c_int = i32, NonZero_c_int = NonZeroI32; } type_alias! { "c_uint.md", c_uint = u32, NonZero_c_uint = NonZeroU32; } type_alias! { "c_long.md", c_long = i32, NonZero_c_long = NonZeroI32;

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
<ins> // Copyright 2014 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 main() { if true { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
} if intrinsic == sym::assert_mem_uninitialized_valid <del> && !fx.tcx.permits_uninit_init(layout) </del> <ins> && !fx.tcx.permits_uninit_init(fx.param_env().and(layout)) </ins> { with_no_trimmed_paths!({ crate::base::codegen_panic(

Discussion:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.
Change:
--> $DIR/uninferred-consts.rs:14:9 | LL |     Foo.foo(); <del> |         ^^^ cannot infer the value of const parameter `N` declared on the associated function `foo` </del> <ins> |         ^^^ cannot infer the value of const parameter `A` declared on the associated function `foo` | help: consider specifying the const argument | LL |     Foo.foo::<A>(); |         ^^^^^^^^ </ins> error: aborting due to previous error

Discussion:
At the moment, we simply emit errors like: It would be good to suggest to the user how to fix this, like with uninferred type arguments.
cc
Stu over has picked this issue up.
Change:
<ins> //! For motivation, see [the reasons](foo#reasons) /// # Reasons /// To test rustdoc json pub fn foo() {} // @set foo = "$.index[*][?(@.name=='foo')].id" // @is "$.index[*][?(@.name=='user_written')].links['foo#reasons']" $foo </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --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:
src/tools/cargo  src/tools/cargotest  $(BOOTSTRAP_ARGS) <del> check-bootstrap: $(Q)$(CFG_PYTHON) $(CFG_SRC_DIR)src/bootstrap/bootstrap_test.py </del> dist: $(Q)$(BOOTSTRAP) dist $(BOOTSTRAP_ARGS) distcheck:

Discussion:
It's very confusing that this can't actually be run through x.py itself; it tripped me up in See for the existing code and for where it should be moved. label +A-rustbuild +E-easy +E-mentor +E-help-wanted +A-contributor-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
#[rustc_const_stable(feature = "rust1", since = "1.0.0")] pub const fn bar2() -> u32 { 42 } <del> // @has 'foo/fn.foo2_gated.html' '//pre' 'pub unsafe fn foo2_gated() -> u32' </del> <ins> // @has 'foo/fn.foo2_gated.html' '//pre' 'pub const unsafe fn foo2_gated() -> u32' </ins> #[unstable(feature = "foo2", issue = "none")] pub const unsafe fn foo2_gated() -> u32 { 42 }

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
"CFG_ENABLE_SCCACHE" if value == "1" => { self.ccache = Some("sccache".to_string()); } <ins> "CFG_CONFIGURE_ARGS" if value.len() > 0 => { self.configure_args = value.split_whitespace() .map(|s| s.to_string()) .collect(); } </ins> _ => {} } }

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
<ins> error: concrete type differs from previous defining opaque type use --> $DIR/recursive-fn-tait.rs:14:5 | LL |     move |x: usize| m(n(x)) |     ^^^^^^^^^^^^^^^^^^^^^^^ expected `{closure@$DIR/recursive-fn-tait.rs:7:5: 7:16}`, got `{closure@$DIR/recursive-fn-tait.rs:14:5: 14:20}` | note: previous use here --> $DIR/recursive-fn-tait.rs:7:5 | LL |     |_: usize |loop {} |     ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test
Change:
/// A synchronization primitive which can be written to only once. /// /// This type is a thread-safe [`OnceCell`], and can be used in statics. <ins> /// In many simple cases, you can use [`LazyLock<T, F>`] instead to get the benefits of this type /// with less effort: `LazyLock<T, F>` "looks like" `&T` because it initializes with `F` on deref! /// Where OnceLock shines is when LazyLock is too simple to support a given case, as LazyLock /// doesn't allow additional inputs to its function after you call [`LazyLock::new(|| ...)`]. </ins> /// /// [`OnceCell`]: crate::cell::OnceCell <ins> /// [`LazyLock<T, F>`]: crate::sync::LazyLock /// [`LazyLock::new(|| ...)`]: crate::sync::LazyLock::new </ins> /// /// # Examples /// <del> /// Using `OnceLock` to store a function’s previously computed value (a.k.a. /// ‘lazy static’ or ‘memoizing’): /// /// ``` /// use std::sync::OnceLock; /// /// struct DeepThought { ///     answer: String, /// } /// /// impl DeepThought { /// #   fn great_question() -> String { /// #       "42".to_string() /// #   } /// # ///     fn new() -> Self { ///         Self { ///             // M3 Ultra takes about 16 million years in --release config ///             answer: Self::great_question(), ///         } ///     } /// } /// /// fn computation() -> &'static DeepThought { ///     // n.b. static items do not call [`Drop`] on program termination, so if ///     // [`DeepThought`] impls Drop, that will not be used for this instance. ///     static COMPUTATION: OnceLock<DeepThought> = OnceLock::new(); ///     COMPUTATION.get_or_init(|| DeepThought::new()) /// } /// /// // The `DeepThought` is built, stored in the `OnceLock`, and returned. /// let _ = computation().answer; /// // The `DeepThought` is retrieved from the `OnceLock` and returned. /// let _ = computation().answer; /// ``` /// </del> /// Writing to a `OnceLock` from a separate thread: /// /// ```

Discussion:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.
Change:
let lllen = self.lvalue_len(bcx, tr_base); let llindex = build::Sub(bcx, lllen, lloffset, DebugLoc::None); let llindex = self.prepare_index(bcx, llindex); <del> (build::InBoundsGEP(bcx, tr_base.llval, &[llindex]), </del> <ins> let zero = common::C_uint(bcx.ccx(), 0u64); (build::InBoundsGEP(bcx, tr_base.llval, &[zero, llindex]), </ins> ptr::null_mut()) } mir::ProjectionElem::Downcast(..) => {

Discussion:
will fail to compile with an LLVM abort: Seems to be a mis-translation of indexing (trans/mir/lvalue at ).
This is not related to According to we might do something incorrectly with GEPs.
That was my first guess, but it seems that is an rvalue with the type , suggesting itself was loaded.
Oh, my first guess was right: all GEPs are but that's not enough. You see, GEP's first index is for the pointer itself. currently gets (mistakenly) translated as instead of the (correct) . All GEP calls should use as the first index and then the index of the array element/struct field.
Change:
pub fn diagnostic<'a>(&'a self) -> &'a errors::Handler { &self.parse_sess.span_diagnostic } <ins> /// Analogous to calling `.span_note` on the given DiagnosticBuilder, but /// deduplicates on lint ID, span, and message for this `Session` if we're /// not outputting in JSON mode. // // FIXME: if the need arises for one-time diagnostics other than // `span_note`, we almost certainly want to generalize this // "check/insert-into the one-time diagnostics map, then set message if // it's not already there" code to accomodate all of them pub fn diag_span_note_once<'a, 'b>(&'a self, diag_builder: &'b mut DiagnosticBuilder<'a>, lint: &'static lint::Lint, span: Span, message: &str) { match self.opts.error_format { // when outputting JSON for tool consumption, the tool might want // the duplicates config::ErrorOutputType::Json => { diag_builder.span_note(span, &message); }, _ => { let lint_id = lint::LintId::of(lint); let id_span_message = (lint_id, span, message.to_owned()); let fresh = self.one_time_diagnostics.borrow_mut().insert(id_span_message); if fresh { diag_builder.span_note(span, &message); } } } } </ins> pub fn codemap<'a>(&'a self) -> &'a codemap::CodeMap { self.parse_sess.codemap() }

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
<ins> // run-rustfix use std::pin::Pin; fn foo(_: &mut ()) {} fn main() { let mut uwu = (); let mut r = Pin::new(&mut uwu); foo(r.get_mut()); foo(r.get_mut()); //~ ERROR use of moved value } </ins>

Discussion:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:
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. // ignore-tidy-tab fn main() { let b = "hello"; let _a = b + ", World!"; //~^ ERROR E0369 } </ins>

Discussion:
This code (containing tabs) gives an error (): The error works fine on stable: But is mispositioned on rustc 1.25.0-nightly ( 2018-01-11) as well as on rustc 1.24.0-beta.2 ( 2018-01-10): cc
Interesting. Im new to code work so following you guys has been extremely helpful thanks
Using bisect-rust I could see that the issue started with , but probably the actual issue is somewhere else (e.g. in the machinery in that starts using for tabs).
Yeah, the issue also exists when emojis are involved (no tabs): Gives: The emoji manifestation of the issue is no beta regression, seems to exist on stable as well.
I've created for the emoji/unicode issue.
It seems to me that the issue only manifests itself in suggestions, and that is handled separately from the main diagnostics. Mentoring instructions:  needs to be modified to use instead of , the start being and the end being ( already accounts for unicode chars). This change should fix both this and .
Will pick this up
Change:
// run-pass <ins> #![allow(non_camel_case_types)] </ins> #![allow(unused_variables)] trait Foo { type bar; fn bar();

Discussion:
Associated types are types and thus should be capitalized. I think most code also does this. Recently I accidentally didn't capitalize it and was surprised that it doesn't lint for it: I'd expect it to say something. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
checking happens inside , add for , then inspect the kind of inside this checking.
I'd like to put my hand up for this if that's alright? It looks like a good one to get started on. claim