jiebi/CodeConvo huggingface dataset:
Change:
Stack smashing protection was in , but  was never updated. label A-docs
Have you started on this already? I'm available to take this on. I came across the docs before the PR, and was misled about the current state of this feature.
Not yet. Sorry about the confusion caused by it. If you'd have time to and would like to contribute, it'd be much appreciated. Feel free to CC me in the PR and I'd be happy to help reviewing it.

Discussion:
<tr> <td>Stack smashing protection </td> <del> <td>No </del> <ins> <td>Yes </ins> </td> <del> <td> </del> <ins> <td>Nightly </ins> </td> </tr> <tr>

when returning from a function. This is also known as “Stack Protector” or “Stack Smashing Protector (SSP)”. <del> The Rust compiler does not support stack smashing protection. However, more comprehensive alternatives to stack smashing protection exist, such as shadow and safe stack (see backward-edge control flow protection). </del> <ins> The Rust compiler supports stack smashing protection on nightly builds[42]. </ins> ![Screenshot of IDA Pro listing cross references to __stack_chk_fail in hello-rust.](images/image3.png "Cross references to __stack_chk_fail in hello-rust.") Fig. 14. IDA Pro listing cross references to `__stack_chk_fail` in hello-rust. To check if stack smashing protection is enabled for a given binary, search <del> for cross references to `__stack_chk_fail`. The only cross references to `__stack_chk_fail` in hello-rust are from the statically-linked libbacktrace library (see Fig. 14). </del> <ins> for cross references to `__stack_chk_fail`. The presence of these cross-references in Rust-compiled code (e.g., `hello_rust::main`) indicates that the stack smashing protection is enabled (see Fig. 14). </ins> ### Forward-edge control flow protection

41. “ControlFlowIntegrity.” The Rust Unstable Book. [https://doc.rust-lang.org/unstable-book/compiler-flags/sanitizer.html#controlflowintegrity](../unstable-book/compiler-flags/sanitizer.html#controlflowintegrity). <ins> 42. bbjornse. “add codegen option for using LLVM stack smash protection #84197.” GitHub. <https://github.com/rust-lang/rust/pull/84197> </ins>
Change:
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. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.

Discussion:
// don't create labels for compiler-generated spans Some(_) => None, None => { <del> let (span, suggestion) = suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ); </del> <ins> let (span, suggestion) = if name != kw::SelfLower { suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ) } else { match local_decl.local_info.as_deref() { Some(LocalInfo::User(ClearCrossCrate::Set( mir::BindingForm::Var(mir::VarBindingForm { opt_ty_info: None, .. }), ))) => { suggest_ampmut_self(self.infcx.tcx, local_decl) } // explicit self (eg `self: &'a Self`) _ => suggest_ampmut( self.infcx.tcx, local_decl, opt_assignment_rhs_span, *opt_ty_info, ), } }; </ins> Some((true, span, suggestion)) } }

<ins> // edition:2018 struct S { foo: usize, } impl S { async fn bar(&self) { //~ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut self self.foo += 1; //~ ERROR cannot assign to `self.foo`, which is behind a `&` reference [E0594] } } fn main() { S { foo: 1 }.bar(); } </ins>

<ins> error[E0594]: cannot assign to `self.foo`, which is behind a `&` reference --> $DIR/issue-93093.rs:8:9 | LL |     async fn bar(&self) { |                  ----- help: consider changing this to be a mutable reference: `&mut self` LL | LL |         self.foo += 1; |         ^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Change:
<!-- 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. --I included the (commented out) workaround I found in case it's helpful. uncomment for a different ICE (Likely a duplicate of ) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-incr-comp
claim

Discussion:
}, ProjectionElem::Field(field, fty) => { let fty = self.sanitize_type(place, fty); <ins> let fty = self.cx.normalize(fty, location); </ins> match self.field_ty(place, base, field, location) { Ok(ty) => { let ty = self.cx.normalize(ty, location);

<ins> // check-pass #![feature(generic_associated_types)] pub trait Fooey: Sized { type Context<'c> where Self: 'c; } pub struct Handle<E: Fooey>(Option<Box<dyn for<'c> Fn(&mut E::Context<'c>)>>); fn tuple<T>() -> (Option<T>,) { (Option::None,) } pub struct FooImpl {} impl Fooey for FooImpl { type Context<'c> = &'c (); } impl FooImpl { pub fn fail1() -> Handle<Self> { let (tx,) = tuple(); Handle(tx) } } fn main() {} </ins>
Change:
Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.

Discussion:
} } } <ins> // just tests by whether or not this compiles fn _pending_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::future::Pending<T>>(); } </ins>

let _: &dyn BuildHasher<Hasher = DefaultHasher> = &RandomState::new(); } <ins> // just tests by whether or not this compiles fn _build_hasher_default_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::hash::BuildHasherDefault<T>>(); } </ins>

let b: Vec<isize> = a.iter().cloned().collect(); assert!(a == b); } <ins> // just tests by whether or not this compiles fn _empty_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::iter::Empty<T>>(); } </ins>
Change:
error: internal compiler error Translating unsupported cast.
Probably shouldn't allow casting nil
The patch above forbids casting from or to nil for now.

Discussion:
let t_1 = ast_ty_to_ty_crate(fcx.ccx, t); let t_e = expr_ty(tcx, e); <ins> if ty::type_is_nil(tcx, t_e) { tcx.sess.span_err(expr.span, "cast from nil: " + ty_to_str(tcx, expr_ty(tcx, e)) + " as " + ty_to_str(tcx, t_1)); } if ty::type_is_nil(tcx, t_1) { tcx.sess.span_err(expr.span, "cast to nil: " + ty_to_str(tcx, expr_ty(tcx, e)) + " as " + ty_to_str(tcx, t_1)); } </ins> // FIXME there are more forms of cast to support, eventually. if !(   type_is_scalar(fcx, expr.span, t_e) && type_is_scalar(fcx, expr.span, t_1)) {

<ins> // error-pattern: cast from nil: () as u32 fn main() { let u = (assert true) as u32; } </ins>  No newline at end of file

<ins> // error-pattern: cast to nil: u32 as () fn main() { let u = 0u32 as (); } </ins>  No newline at end of file
Change:
<!-- 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</detailsThanks for investigating into this issue! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
... I found that I forget to impl and for bool. Even if I do: The issue still exists...
claim

Discussion:
let predicate = predicate.fold_with(&mut BottomUpFolder { tcx, ty_op: |ty| match ty.kind() { <del> ty::Projection(projection_ty) => infcx.infer_projection( self.param_env, *projection_ty, traits::ObligationCause::misc(self.value_span, self.body_id), 0, &mut self.obligations, ), </del> <ins> ty::Projection(projection_ty) if !projection_ty.has_escaping_bound_vars() => { infcx.infer_projection( self.param_env, *projection_ty, traits::ObligationCause::misc(self.value_span, self.body_id), 0, &mut self.obligations, ) } </ins> _ => ty, }, lt_op: |lt| lt,

<ins> // check-pass #![feature(generic_associated_types)] pub trait Scalar: 'static { type RefType<'a>: ScalarRef<'a>; } pub trait ScalarRef<'a>: 'a {} fn cmp_eq<'a, 'b, A: Scalar, B: Scalar, O: Scalar>(a: A::RefType<'a>, b: B::RefType<'b>) -> O { todo!() } fn build_expression<A: Scalar, B: Scalar, O: Scalar>( ) -> impl Fn(A::RefType<'_>, B::RefType<'_>) -> O { cmp_eq } fn main() {} </ins>
Change:
<!-- 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 am trying to build Rust from source on my project's continuous integration system. I see the following error: Looking at the message and it seems the intent is to prevent putting root-owned files in a non-root user's home directory. Our CI builders use sudo to step down from root to a sandboxed user. See for an example environment. I believe it should be safe to build without vendoring in this case. should skip the check if SUDOUSER is not root, or an option to bypass this check should be provided. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
If the implementation for this is relatively straightforward, a PR is likely to be accepted.
label; +E-easy +E-help-wanted
Error: Parsing relabel command in failed: ...'tbot label' '; +E-easy '... Please let know if you're having trouble with this bot.
label: +E-easy +E-help-wanted
claim

Discussion:
"""Check that vendoring is configured properly""" vendor_dir = os.path.join(self.rust_root, 'vendor') if 'SUDO_USER' in os.environ and not self.use_vendored_sources: <del> if os.environ.get('USER') != os.environ['SUDO_USER']: </del> <ins> if os.getuid() == 0: </ins> self.use_vendored_sources = True <del> print('info: looks like you are running this command under `sudo`') </del> <ins> print('info: looks like you're trying to run this command as root') </ins> print('      and so in order to preserve your $HOME this will now') print('      use vendored sources by default.') if not os.path.exists(vendor_dir):
Change:
runner: x8664-gnu-llvm-12, ubuntu-20.04-xl Occured in multiple pr across CI: : : : : and others
Possibly this was ? Looking at what's been merged in the last day, that seems to be the most relevant thing
You mean it might have introduced a new miscompilation that made compiletest crash?
Maybe. Its also possible that there was some existing UB elsewhere that happened to get set off by this, don't really know. My observation just mostly comes from where the segfault is happening and what commits in the last day have touched nearby code
Why this even triggered? Looks unrelated, but still suspicious.
Those warnings are unrelated. I'll post a patch soon to fix it. EDIT:
Funny thing: been merged even with crashed compiletest: , how this works?
The comment by is about the CI run not the bors run.
Yes, it failed on PR check, not on check-all-platforms-and-merge. So fast approving PR, so it merged even with failed PR check :-(
can you try to revert that pr and see, will it fail or not on test?
Yeah, I can do that before the end of the day
Reverting didn't fix it. Its still very suspicious that this started right after that got merged though. I'll leave the branch up on my fork for a little in case anyone else wants to re-run things or something.
The issue appears to be caused by a copy of dirent made in . Only a part of the structure as described by is actually dereferenceable: Which was recently changed for Linux and Android in .
It sounds like reverting that PR would be a good first step, since the bugs it fixes look less critical to me given that diagnosis. (Of course, maybe there is a more forward-moving fix, but a revert seems like something we can merge with less caution). cc
I'll take a look. do you mean the part? I didn't expect but maybe it's possible.
Oh indeed that seems to happen all the time. One sec I'll put up a patch

Discussion:
let path = Path::new(""); assert_eq!(path.canonicalize().unwrap_err().kind(), crate::io::ErrorKind::NotFound); } <ins> /// Ensure ReadDir works on large directories. /// Regression test for https://github.com/rust-lang/rust/issues/93384. #[test] fn read_large_dir() { let tmpdir = tmpdir(); let count = 32 * 1024; for i in 0..count { check!(fs::File::create(tmpdir.join(&i.to_string()))); } for entry in fs::read_dir(tmpdir.path()).unwrap() { entry.unwrap(); } } </ins>

}; } <ins> // Only d_reclen bytes of *entry_ptr are valid, so we can't just copy the // whole thing (#93384).  Instead, copy everything except the name. let entry_bytes = entry_ptr as *const u8; let entry_name = ptr::addr_of!((*entry_ptr).d_name) as *const u8; let name_offset = entry_name.offset_from(entry_bytes) as usize; let mut entry: dirent64 = mem::zeroed(); ptr::copy_nonoverlapping(entry_bytes, &mut entry as *mut _ as *mut u8, name_offset); </ins> let ret = DirEntry { <del> entry: *entry_ptr, </del> <ins> entry, </ins> // d_name is guaranteed to be null-terminated. <del> name: CStr::from_ptr((*entry_ptr).d_name.as_ptr()).to_owned(), </del> <ins> name: CStr::from_ptr(entry_name as *const _).to_owned(), </ins> dir: Arc::clone(&self.inner), }; if ret.name_bytes() != b"." && ret.name_bytes() != b".." {
Change:
It'd be good to minimize this and reproduce this outside of rustc. ! !
This bisects to . Stop looking at me like that! is still a thing! And no, before someone asks, I do not volunteer to do this sort of thing on a regular basis. It took all day. I did other stuff at the same time, but still...
Thank you so much! FYI, using  (with and ) would've probably been a lot faster :)
cc
I guess the issue here is that is erasing the lifetimes (=regions) in the type, hence its name. cc as well
I'm working on it.
I feel very embarrassed. I figured that it wouldn't work, because generally cargo explodes whenever I try to use it on the compiler. I take it would actually work though?
Actually, I think you're right to use . cargo-bisect-rustc doesn't usually work on the compiler Sorry about that!
The underlying principle should work though, by specifying rustc = ... in pointing to a rustup-toolchain-install-master'd binary (and potentially cargo = and/or rustdoc =).

Discussion:
return None; } <ins> use crate::rustc_trait_selection::infer::TyCtxtInferExt; use crate::rustc_trait_selection::traits::query::normalize::AtExt; use rustc_middle::traits::ObligationCause; </ins> // Try to normalize `<X as Y>::T` to a type let lifted = ty.lift_to_tcx(cx.tcx).unwrap(); <del> match cx.tcx.try_normalize_erasing_regions(cx.param_env, lifted) { </del> <ins> let normalized = cx.tcx.infer_ctxt().enter(|infcx| { infcx .at(&ObligationCause::dummy(), cx.param_env) .normalize(lifted) .map(|resolved| infcx.resolve_vars_if_possible(resolved.value)) }); match normalized { </ins> Ok(normalized_value) => { <del> trace!("normalized {:?} to {:?}", ty, normalized_value); </del> <ins> debug!("normalized {:?} to {:?}", ty, normalized_value); </ins> Some(normalized_value) } Err(err) => { <del> info!("failed to normalize {:?}: {:?}", ty, err); </del> <ins> debug!("failed to normalize {:?}: {:?}", ty, err); </ins> None } }

<ins> #![crate_name = "foo"] // @has 'foo/type.Resolutions.html' // @has - '//*[@class="rust typedef"]' "pub type Resolutions<'tcx> = &'tcx u8;" pub type Resolutions<'tcx> = &'tcx u8; </ins>
Change:
As of now, the stable and nightly documentation on only states And proceeds to note a couple of errors the function may fail with. This does not mention the fact that (as far as I am aware, testing on Linux) the path is also canonicalized, having resolved all symlinks in any segment of the path. I'd imagine not documenting this behavior could lead to confusion and/or bugs, if it already hasn't. I tried this code within a symlink folder pointing to : I expected to see get the output: Instead, this was output: Currently using the nightly compiler. For obvious reasons, there's no backtrace. Update: Read a bit through the code and realized this behavior might be libc-dependent on my system returns
For UNIX Rust just calls and that behavior is documented in the , so it will be the same on all conforming implementations. We should document which platform-specific function we call here just like we do with other filesystem functions (e.g. ). label T-libs A-docs
It was also missing for so I opened for both.
Thanks a lot

Discussion:
/// Returns the current working directory as a [`PathBuf`]. /// <ins> /// # Platform-specific behavior /// /// This function currently corresponds to the `getcwd` function on Unix /// and the `GetCurrentDirectoryW` function on Windows. /// </ins> /// # Errors /// /// Returns an [`Err`] if the current working directory value is invalid.

/// Changes the current working directory to the specified path. /// <ins> /// # Platform-specific behavior /// /// This function currently corresponds to the `chdir` function on Unix /// and the `SetCurrentDirectoryW` function on Windows. /// </ins> /// Returns an [`Err`] if the operation fails. /// /// # Examples
Change:
The only mentions 's use with loops, but that keyword has one other use that I am aware of, specifying a visibility path for an item, . This should be documented there as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
/// [`IntoIterator`]: ../book/ch13-04-performance.html /// [range patterns]: ../reference/patterns.html?highlight=range#range-patterns /// [`for`]: keyword.for.html <ins> /// /// The other use of `in` is with the keyword `pub`. It allows users to declare an item as visible /// only within a given scope. /// /// ## Literal Example: /// ///    * `pub(in crate::outer_mod) fn outer_mod_visible_fn() {}` - fn is visible in `outer_mod` /// /// Starting with the 2018 edition, paths for `pub(in path)` must start with `crate`, `self` or /// `super`. The 2015 edition may also use paths starting with `::` or modules from the crate root. /// /// For more information, see the [Reference]. /// /// [Reference]: ../reference/visibility-and-privacy.html#pubin-path-pubcrate-pubsuper-and-pubself </ins> mod in_keyword {} #[doc(keyword = "let")]
Change:
It seems pretty strange to me that the env variable would take precedence over --config. It would be nice to switch the precedence. cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Added in ; it seems like it makes sense for --config to override, though probably not typically all that useful. Happy to see a PR, should be pretty easy so marking as such.
claim

Discussion:
build.verbose = args.verbose build.clean = args.clean <del> # Read from `RUST_BOOTSTRAP_CONFIG`, then `--config`, then fallback to `config.toml` (if it </del> <ins> # Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then fallback to `config.toml` (if it </ins> # exists). <del> toml_path = os.getenv('RUST_BOOTSTRAP_CONFIG') or args.config </del> <ins> toml_path = args.config or os.getenv('RUST_BOOTSTRAP_CONFIG') </ins> if not toml_path and os.path.exists('config.toml'): toml_path = 'config.toml'
Change:
<!-- 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: I expected an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler

Discussion:
), // Entry point: <del> ungated!(main, Normal, template!(Word), WarnFollowing), </del> ungated!(start, Normal, template!(Word), WarnFollowing), ungated!(no_start, CrateLevel, template!(Word), WarnFollowing), ungated!(no_main, CrateLevel, template!(Word), WarnFollowing),

<ins> #[main]  //~ ERROR cannot find attribute `main` in this scope fn main() {} </ins>

<ins> error: cannot find attribute `main` in this scope --> $DIR/main-removed-1.rs:1:3 | LL | #[main] |   ^^^^ | = note: `main` is in scope, but it is a function, not an attribute error: aborting due to previous error </ins>

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn main(_: TokenStream, input: TokenStream) -> TokenStream { "fn main() { println!("Hello Tokyo!"); }".parse().unwrap() } </ins>

<ins> // run-pass // aux-build:tokyo.rs // compile-flags:--extern tokyo // edition:2021 use tokyo::main; #[main] fn main() { panic!("the #[main] macro should replace this with non-panicking code") } </ins>