jiebi/CodeConvo huggingface dataset:
Change:
In Rust 1.28, building the full compiler with full debuginfo (as we do in Fedora) sees debuginfo errors with external LLVM5 (Fedora 27 and EPEL7). Fedora 28+ with LLVM6 looks fine. For example, from the logs in : I believe this is the effect of , per I reverted that commit locally, and it looks like this has fixed it. Maybe we can keep that hack in place just for LLVM5? (skipping it on LLVM6+)

Discussion:
}; let upvar_tys = upvar_substs.upvar_tys(def_id, tcx); <ins> // Store the pointer to closure data in an alloca for debuginfo // because that's what the llvm.dbg.declare intrinsic expects. // FIXME(eddyb) this shouldn't be necessary but SROA seems to // mishandle DW_OP_plus not preceded by DW_OP_deref, i.e. it // doesn't actually strip the offset when splitting the closure // environment into its components so it ends up out of bounds. // (cuviper) It seems to be fine without the alloca on LLVM 6 and later. let env_alloca = !env_ref && unsafe { llvm::LLVMRustVersionMajor() < 6 }; let env_ptr = if env_alloca { let scratch = PlaceRef::alloca(bx, bx.cx.layout_of(tcx.mk_mut_ptr(arg.layout.ty)), "__debuginfo_env_ptr"); bx.store(place.llval, scratch.llval, scratch.align); scratch.llval } else { place.llval }; </ins> for (i, (decl, ty)) in mir.upvar_decls.iter().zip(upvar_tys).enumerate() { let byte_offset_of_var_in_env = closure_layout.fields.offset(i).bytes();

}; // The environment and the capture can each be indirect. <del> let mut ops = if env_ref { &ops[..] } else { &ops[1..] }; </del> <ins> // FIXME(eddyb) see above why we sometimes have to keep // a pointer in an alloca for debuginfo atm. let mut ops = if env_ref || env_alloca { &ops[..] } else { &ops[1..] }; </ins> let ty = if let (true, &ty::TyRef(_, ty, _)) = (decl.by_ref, &ty.sty) { ty

}; let variable_access = VariableAccess::IndirectVariable { <del> alloca: place.llval, </del> <ins> alloca: env_ptr, </ins> address_operations: &ops }; declare_local(
Change:
I got a compiler crash and idk what any of it means but here you go. I tried this code: . I expected to see this happen: stuff would work Instead, this happened: Rust was eaten by velociraptors. :
Smaller example:
Reduced some more:

Discussion:
} else { None } { <ins> self.set_tainted_by_errors(); // #53251 </ins> err.span_label(span, format!("expected {}", expected_text)).emit(); }

<ins> // Copyright 2018 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. struct S; impl S { fn f() {} } macro_rules! impl_add { ($($n:ident)*) => { $( fn $n() { S::f::<i64>(); //~^ ERROR too many type parameters provided } )* } } impl_add!(a b); </ins>

<ins> error[E0601]: `main` function not found in crate `issue_53251` | = note: consider adding a `main` function to `$DIR/issue-53251.rs` error[E0087]: too many type parameters provided: expected at most 0 type parameters, found 1 type parameter --> $DIR/issue-53251.rs:21:24 | LL |                 S::f::<i64>(); |                        ^^^ expected 0 type parameters ... LL | impl_add!(a b); | --------------- in this macro invocation error: aborting due to 2 previous errors Some errors occurred: E0087, E0601. For more information about an error, try `rustc --explain E0087`. </ins>
Change:
When compiling () with the command I receive the following ICE: reports:
The error reproduces on Travis: https://travis-
Minimal changes needed to trigger / prevent ICE: (no ICE) (ICE)
It would be great if someone could test this on a recent rustc and if it still fails, try to minimize it
I had to to make it "compile" again, but I still get an ICE with a recent :
Awesome! thanks for the quick work.
Do you think you could reduce this further?
I just tried to reproduce this once more with and instead of an ICE it now produces multiple compilation errors, such as: This pretty much seems to "prevent" how I could previously ICE it, enabling or disabling macro invocations with an empty array that then got accessed: Seems like this got fixed. On a side note, I'm positively surprised it detects this will panic at runtime, although one could make the argument that maybe I wanted that macro expansion to panic inside a unit test, and therefore emitting a compilation error is too strong. (Update) Hm, strangely enough, the error generation is only triggered when running , not when running (even if I move the invalid array access into the main library). It still doesn't ICE, but it also doesn't produce the errors.
Cool; ideally, if we could create a minimal example that we could add as a regression test that would be great, and if not, then I guess we'll close the issue as it no longer ICEs.
Alright, here is the MVP that would do it: When I run this with on it would ICE as above; with the latest it just gives an error.
Thanks, cc

Discussion:
<ins> // build-pass #![crate_type = "lib"] #![allow(unconditional_panic)] struct S(u8); pub fn ice() { S([][0]); } </ins>
Change:
Want to fix this bug? There are . This github repository does not contain a trademark file, and I am curious if still applies, as it would seem. Debian and some other distributions are applying patches against the Rust language and Cargo package. I assume this qualifies as something which requires explicit approval? If so, removing or restricting packages from Cargo would also be considered a modification. e.g. some distributions may wish to block access to Cargo downloads that are not in compliance with license standards. Just wanted to get some clarification on this as it is not mentioned here in the repo and some folks seems to think that because there is no trademark "here" that rust-lang can be distributed with modifications without approval. I believe the only way such modifications would be allowed unrestricted, is if "rust" was not used at all in the package and it was clearly defined as a rebranded fork that is not affiliated with the official package - Otherwise the trademark policy is still enforced.
This question should be asked at the linked on the Legal page rather than here.
Just received a response. It seems a may be useful to direct people to the appropriate from github. This issue can be closed once trademark notification is included or mentioned on Thank you.
I've tagged this issue as and . To close this bug, we should add a new section to that mentions that there are trademarks on the rust name and logo, and link to If you want to fix this bug and need any help, please let me know, and I'm happy to assist!
Hi I'd like to work on this and opened to add a section about trademarks. But I'm not sure whether I made appropriate wording. Could you please help to review? Thanks a lot.
Any news regarding this ^ Cheers

Discussion:
See [LICENSE-APACHE](LICENSE-APACHE), [LICENSE-MIT](LICENSE-MIT), and [COPYRIGHT](COPYRIGHT) for details. <ins> ## Trademark [trademark]: #trademark The Rust programming language is an open source, community project governed by a core team. It is also sponsored by the Mozilla Foundation (“Mozilla”), which owns and protects the Rust and Cargo trademarks and logos (the “Rust Trademarks”). If you want to use these names or brands, please read the [media guide][media-guide]. Third-party logos may be subject to third-party copyrights and trademarks. See [Licenses][policies-licenses] for details. [media-guide]: https://www.rust-lang.org/policies/media-guide [policies-licenses]: https://www.rust-lang.org/policies/licenses </ins>
Change:
and undo the const -fn changes in This requires changing applicable methods on from to , adding the attribute to all of them and adding some tests ensuring that the methods are not const fn on stable rust.
Ah, no, it requires conditional control-flow.
Ah I thought there were more trivial methods. This issue is only acctionable for at the moment
Hi, I'd like to help out on this. I would appreciate if some one gave me pointers on what needs to be accomplished.
Steps: to the attribute a test in that shows a const usage of the method (needs the feature gate specified in whether the linked commit above can be partially reverted
you may take a look at . These are the steps you have to do in order to add .
I will do that sir. Was busy with my internship.
If you need help, don't hesitate to ping me here, in Discord (Cyres) or on in the rust chat room.
Thank you

Discussion:
/// Returns the value as a primitive type. #[stable(feature = "nonzero", since = "1.28.0")] #[inline] <del> pub fn get(self) -> $Int { </del> <ins> pub const fn get(self) -> $Int { </ins> self.0 }

<ins> // compile-pass use std::num::NonZeroU8; const X: NonZeroU8 = unsafe { NonZeroU8::new_unchecked(5) }; const Y: u8 = X.get(); fn main() { } </ins>
Change:
A thing works fine when compiled with stable rust, but fails at runtime with nightly. I tried this code: I expected this to happen: It'd compile and work, just like it used to. Instead, this happened: It appears it has to do something with Specifically, changing them to take f64 instead fails with: :
Now pushed to stable 1.29. Great.
Cc
Ah it looks like this is a symbol conflict error: You'll want to rename your import as it conflicts with the symbol in compiler-rt
Oh, I see, thanks!

Discussion:
// Make the default table accessible self.cmd.arg("--export-table"); <ins> // Rust code should never have warnings, and warnings are often // indicative of bugs, let's prevent them. self.cmd.arg("--fatal-warnings"); </ins> let mut cmd = Command::new(""); ::std::mem::swap(&mut cmd, &mut self.cmd); cmd
Change:
I made a struct , and made two blocks for and ( and are unit structs.) Each block has a method with same name but different argument count. I accidentally made those methods private. [Link to the playground][playground] [playground]: I expected to get error about privacy, but with that, the compiler panicked. Backtrace: <details</details
A more minimal repro:
Interesting point: in this code, doesn't have method but the compiler reports that it exists but is private. However, with , the compiler reports error correctly.
CC , .

Discussion:
match self.at(&self.misc(span), self.param_env).sup(impl_ty, self_ty) { Ok(ok) => self.register_infer_ok_obligations(ok), Err(_) => { <del> span_bug!(span, </del> <ins> self.tcx.sess.delay_span_bug(span, &format!( </ins> "instantiate_value_path: (UFCS) {:?} was a subtype of {:?} but now is not?", self_ty, <del> impl_ty); </del> <ins> impl_ty, )); </ins> } } }

<ins> pub mod test { pub struct A; pub struct B; pub struct Foo<T>(T); impl Foo<A> { fn foo() {} } impl Foo<B> { fn foo() {} } } fn main() { test::Foo::<test::B>::foo(); //~ ERROR method `foo` is private } </ins>

<ins> error[E0624]: method `foo` is private --> $DIR/issue-53498.rs:16:5 | LL |     test::Foo::<test::B>::foo(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0624`. </ins>
Change:
I wanted to link somebody to documentation explaining that you can dereference a to move the value onto the stack, but... neither the module nor mention this or show any examples!
Opened a PR for this:

Discussion:
//! //! # Examples //! <del> //! Creating a box: </del> <ins> //! Move a value from the stack to the heap by creating a [`Box`]: </ins> //! //! ``` <del> //! let x = Box::new(5); </del> <ins> //! let val: u8 = 5; //! let boxed: Box<u8> = Box::new(val); //! ``` //! //! Move a value from a [`Box`] back to the stack by [dereferencing]: //! //! ``` //! let boxed: Box<u8> = Box::new(5); //! let val: u8 = *boxed; </ins> //! ``` //! //! Creating a recursive data structure:

//! elements are in the list, and so we don't know how much memory to allocate //! for a `Cons`. By introducing a `Box`, which has a defined size, we know how //! big `Cons` needs to be. <ins> //! //! [dereferencing]: ../../std/ops/trait.Deref.html //! [`Box`]: struct.Box.html </ins> #![stable(feature = "rust1", since = "1.0.0")]
Change:
Indexing into a slice relies on , which says that its UB to use an offset/index larger than . As documented by , "memory acquired directly from allocators or memory mapped files may be too large to handle with this function." Does that mean that e.g. memory mapping a file larger than into a slice is unsound, because safe code can cause UB just by indexing into it? Should the  docs tell callers that they need to check this?

Discussion:
use cmp; use fmt; use intrinsics::assume; <ins> use isize; </ins> use iter::*; use ops::{FnMut, Try, self}; use option::Option;

/// them from other data. You can obtain a pointer that is usable as `data` /// for zero-length slices using [`NonNull::dangling()`]. /// <ins> /// The total size of the slice must be no larger than `isize::MAX` **bytes** /// in memory. See the safety documentation of [`pointer::offset`]. /// </ins> /// # Caveat /// /// The lifetime for the returned slice is inferred from its usage. To

/// ``` /// /// [`NonNull::dangling()`]: ../../std/ptr/struct.NonNull.html#method.dangling <ins> /// [`pointer::offset`]: ../../std/primitive.pointer.html#method.offset </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] { debug_assert!(data as usize % mem::align_of::<T>() == 0, "attempt to create unaligned slice"); <ins> debug_assert!(mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize, "attempt to create slice covering half the address space"); </ins> Repr { raw: FatPtr { data, len } }.rust }

/// This function is unsafe for the same reasons as [`from_raw_parts`], as well /// as not being able to provide a non-aliasing guarantee of the returned /// mutable slice. `data` must be non-null and aligned even for zero-length <del> /// slices as with [`from_raw_parts`]. See the documentation of /// [`from_raw_parts`] for more details. </del> <ins> /// slices as with [`from_raw_parts`]. The total size of the slice must be no /// larger than `isize::MAX` **bytes** in memory. /// /// See the documentation of [`from_raw_parts`] for more details. </ins> /// /// [`from_raw_parts`]: ../../std/slice/fn.from_raw_parts.html #[inline] #[stable(feature = "rust1", since = "1.0.0")] pub unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T] { debug_assert!(data as usize % mem::align_of::<T>() == 0, "attempt to create unaligned slice"); <del> Repr { raw: FatPtr { data, len} }.rust_mut </del> <ins> debug_assert!(mem::size_of::<T>().saturating_mul(len) <= isize::MAX as usize, "attempt to create slice covering half the address space"); Repr { raw: FatPtr { data, len } }.rust_mut </ins> } /// Converts a reference to T into a slice of length 1 (without copying).
Change:
When compiling this warning is generated: I think, in the derive does not consider this lint.
I tried to in the compiler but hit this bug, which makes it a non-starter. I'd almost change built-in deriving to not declare the lifetimes explicitly but I suspect that wouldn't work when using nested within a block where the shadowing from explicitness would be useful. (That's assuming built-in deriving actually uses these lifetimes in bounds, otherwise it could just use ) cc
cc
I don't think this seems high priority. I'll leave it nominated but I'm prioritizing it as P-medium.
The problem is that the above code expands to something similar to which correctly warns for the in the . But since in the original code the impl is derived and reusesthe from the struct declaration, the lint appears to trigger on the struct declaration. We may either just want to not trigger in derive expansions or explicitly allow this lint in derives expansions.
advertised at T-compiler meeting. removing nomination tag.
I'm going to ping in the hopes that they have a bit of time to look into this. My sense is that we ought to make a plan to finish up the Rust 2018 idiom lints -- but at the same time it's hard to justify a P-high label just now.
I tried an approach where I would look at the lifetime span to see if it came from a compiler desugaring, but the derived code doesn't keep any information about their context. A different approach will be needed in the parse step to make sure the debug subparser produced spans are appropriately marked. I won't have time to dig deeper, but wanted to share what I found.
AFAIK there's a perma-unstable attribute that is placed on derived s which some error reporting code might be checking. I should've given more context - it'd be good to fix this because it would unblock something like , but likely removing a far larger number of lifetimes, which may simplify e.g. the removal. But if we can't really soon, we can defer indefinitely, I think.
?
This seems to have regressed.

Discussion:
continue; } <ins> if let Some(parent_def_id) = self.tcx.parent(def_id) { if let Some(parent_hir_id) = self.tcx.hir() .as_local_hir_id(parent_def_id) { // lifetimes in `derive` expansions don't count (Issue #53738) if self.tcx.hir().attrs_by_hir_id(parent_hir_id).iter() .any(|attr| attr.check_name(sym::automatically_derived)) { continue; } } } </ins> let mut err = self.tcx.struct_span_lint_hir( lint::builtin::SINGLE_USE_LIFETIMES, id,

trait Baz<'f> { } <ins> // `Derive`d impls shouldn't trigger a warning, either (Issue #53738). #[derive(Debug)] struct Quux<'a> { priors: &'a u32, } </ins> fn main() { }
Change:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.

Discussion:
} fn name_key(name: &str) -> (&str, u64, usize) { <ins> let end = name.bytes() .rposition(|b| b.is_ascii_digit()).map_or(name.len(), |i| i + 1); </ins> // find number at end <del> let split = name.bytes().rposition(|b| b < b'0' || b'9' < b).map_or(0, |s| s + 1); </del> <ins> let split = name[0..end].bytes() .rposition(|b| !b.is_ascii_digit()).map_or(0, |i| i + 1); </ins> // count leading zeroes let after_zeroes = <del> name[split..].bytes().position(|b| b != b'0').map_or(name.len(), |extra| split + extra); </del> <ins> name[split..end].bytes().position(|b| b != b'0').map_or(name.len(), |extra| split + extra); </ins> // sort leading zeroes last let num_zeroes = after_zeroes - split; <del> match name[split..].parse() { </del> <ins> match name[split..end].parse() { </ins> Ok(n) => (&name[..split], n, num_zeroes), Err(_) => (name, 0, num_zeroes), }

bounds } <ins> fn compare_impl<'a, 'b>(lhs: &'a &&Impl, rhs: &'b &&Impl) -> Ordering { let lhs = format!("{}", lhs.inner_impl()); let rhs = format!("{}", rhs.inner_impl()); // lhs and rhs are formatted as HTML, which may be unnecessary name_key(&lhs).cmp(&name_key(&rhs)) } </ins> fn item_trait( w: &mut fmt::Formatter, cx: &Context,

.map_or(true, |d| cache.paths.contains_key(&d))); <del> let (synthetic, concrete): (Vec<&&Impl>, Vec<&&Impl>) = local.iter() </del> <ins> let (mut synthetic, mut concrete): (Vec<&&Impl>, Vec<&&Impl>) = local.iter() </ins> .partition(|i| i.inner_impl().synthetic); <ins> synthetic.sort_by(compare_impl); concrete.sort_by(compare_impl); </ins> if !foreign.is_empty() { write!(w, " <h2 id='foreign-impls' class='small-section-header'>

"Fruit1", "Fruit01", "Fruit2", "Fruit02", "Fruit20", <ins> "Fruit30x", </ins> "Fruit100", "Pear"]; let mut sorted = names.to_owned();

<ins> // Copyright 2018 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. pub trait MyIterator { } pub struct MyStruct<T>(T); macro_rules! array_impls { ($($N:expr)+) => { $( impl<'a, T> MyIterator for &'a MyStruct<[T; $N]> { } )+ } } // @has issue_53812/trait.MyIterator.html '//*[@id="implementors-list"]//h3[1]' 'MyStruct<[T; 0]>' // @has - '//*[@id="implementors-list"]//h3[2]' 'MyStruct<[T; 1]>' // @has - '//*[@id="implementors-list"]//h3[3]' 'MyStruct<[T; 2]>' // @has - '//*[@id="implementors-list"]//h3[4]' 'MyStruct<[T; 3]>' // @has - '//*[@id="implementors-list"]//h3[5]' 'MyStruct<[T; 10]>' array_impls! { 10 3 2 1 0 } </ins>
Change:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.

Discussion:
with explanations of how to use various things, as well as example code for accomplishing various tasks. <ins> <div> <form action="std/index.html" method="get"> <input type="search" name="search"/> <button>Search</button> </form> </div> </ins> ## The Rustc Book [The Rustc Book](rustc/index.html) describes the Rust compiler, `rustc`.
Change:
, the inner span to the format string is shifted 1 character to the right for each newline. Introduced in .
I would like to help with this issue. May someone give me some information about how I can help?
I believe one of the uses of should be there, which causes the span to be shifter by one for each newline, . You should modify to include the incorrect case in the description, and use to update the corresponding file. You can use to see if the change you made is actually doing what you expect it to do.

Discussion:
self.cur.next(); Some(pos) } else { <del> let pos = pos + padding + 1; </del> <ins> let pos = pos + raw + 1; </ins> self.err(format!("expected `{:?}`, found `{:?}`", c, maybe), format!("expected `{}`", c), pos,

"##); //~^^^ ERROR: there is no argument named `foo` <ins> // bad syntax in format string with multiple newlines, #53836 format!("first number: {} second number: {} third number: {} fourth number: {} fifth number: {} sixth number: {} seventh number: {} eighth number: {} ninth number: { tenth number: {}", 1, 2, 3, 4, 5, 6, 7, 8, 9, 10); //~^^ ERROR: invalid format string </ins> }

LL |         {foo} |         ^^^^^ <del> error: aborting due to 27 previous errors </del> <ins> error: invalid format string: expected `'}'`, found `'t'` --> $DIR/ifmt-bad-arg.rs:85:1 | LL | tenth number: {}", | ^ expected `}` in format string error: aborting due to 28 previous errors </ins>