jiebi/CodeConvo huggingface dataset:
Change:
I forgot a lone without any arguments given to the macro. This was in one of the modules of my code (not ). The consequences are quite painful: The compilation fails with: So the issue is that I expected an error message indicating the file where my wrong macro call was made and the line number. Instead I got this error message with no location information nor any reference to a macro. I had to comment/uncomment all my new modules/functions/lines to find my incorrect macro call. I could reproduce the issue with , but not with the later gives a useful error message . So this must affect only some macros. rustc --version --verbose rustc 1.30.0 ( 2018-10-24) binary: rustc commit-hash: commit-date: 2018-10-24 host: x8664-unknown-linux-gnu release: 1.30.0 LLVM version: 8.0
Can you check your code against nightly? I believe this might have been fixed by .
still an issue on nightly:

Discussion:
tts: &[TokenTree], ) -> Box<dyn MacResult + 'cx> { let mut parser = cx.new_parser_from_tts(tts); <ins> if parser.token == token::Eof { cx.struct_span_err(sp, "macro requires a boolean expression as an argument") .span_label(sp, "boolean expression required") .emit(); return DummyResult::expr(sp); } </ins> let cond_expr = panictry!(parser.parse_expr()); let custom_msg_args = if parser.eat(&token::Comma) { let ts = parser.parse_tokens();

<ins> fn main() { assert!();  //~ ERROR requires a boolean expression debug_assert!(); //~ ERROR requires a boolean expression } </ins>

<ins> error: macro requires a boolean expression as an argument --> $DIR/assert.rs:2:5 | LL |     assert!();  //~ ERROR requires a boolean expression |     ^^^^^^^^^^ boolean expression required error: macro requires a boolean expression as an argument --> $DIR/assert.rs:3:5 | LL |     debug_assert!(); //~ ERROR requires a boolean expression |     ^^^^^^^^^^^^^^^^ boolean expression required | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to 2 previous errors </ins>
Change:
https://crater-, This appears to ICE on nightly so maybe that's the underlying cause? cc
Fixed in

Discussion:
None => continue, }; <del> if binding.is_import() || binding.is_macro_def() { </del> <ins> // Filter away "empty import canaries". let is_non_canary_import = binding.is_import() && binding.vis != ty::Visibility::Invisible; if is_non_canary_import || binding.is_macro_def() { </ins> let def = binding.def(); if def != Def::Err { if let Some(def_id) = def.opt_def_id() {

<ins> mod m {} // These two imports should not conflict when this crate is loaded from some other crate. use m::{}; use m::{}; </ins>

<ins> // compile-pass // aux-build:issue-55811.rs extern crate issue_55811; fn main() {} </ins>
Change:
Spawned off of (specificially in the project). Consider the following code: With AST-borrowck, you get (): With NLL (here using migration a la 2018 edition), you get (): I have not managed to replicate the above borrow-check error on code that does not exhibit some other error. And the problem goes away if you opt into (). So, this is really a very minor diagnostic issue.
Cc might be something in (min) const qualification?
TLDR: The issue with this is that we have a bunch of separate checks relating to const things, and most of these are spaghetti entangled into one. and I are working towards fixing that, but it's nontrivial to say the least. Details: We have the following checks that we need to run on MIR (which relate to const): minconstfn compliance constfn compliance promotion of runtime values to an anonymous static/constant const compliance (valid array length, const item initializer or enum discriminant) static compliance (valid static item initializer) no interior mutability checks no drop in const checks The current implementation has an early abort for const fns where if the feature gate is not active, we first run , and if that fails we don't run the entangled other 4 passes. If we ran the other passes in case of failure, you'd get a lot of error duplication. I don't think we have a tracking issue for the refactoring separating all these passes into distinct dataflow passes, but there's ongoing work.
This now produces the same output both with and without .

Discussion:
<ins> // Regression test for issue #55825 // Tests that we don't emit a spurious warning in NLL mode #![feature(nll)] const fn no_dyn_trait_ret() -> &'static dyn std::fmt::Debug { &() } //~ ERROR const fn main() { } </ins>

<ins> error[E0658]: trait objects in const fn are unstable --> $DIR/issue-55825-const-fn.rs:6:32 | LL | const fn no_dyn_trait_ret() -> &'static dyn std::fmt::Debug { &() } |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information = help: add `#![feature(const_fn_trait_bound)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>
Change:
As far as I know doens't sync data onto disk on macos. (Depending on kernel & file system it might not do so on linux either). Which is why does use on mac for and implies syncing data, so shouldn't it use fcntl, too?

Discussion:
} pub fn fsync(&self) -> io::Result<()> { <del> cvt_r(|| unsafe { libc::fsync(self.0.raw()) })?; Ok(()) </del> <ins> cvt_r(|| unsafe { os_fsync(self.0.raw()) })?; return Ok(()); #[cfg(any(target_os = "macos", target_os = "ios"))] unsafe fn os_fsync(fd: c_int) -> c_int { libc::fcntl(fd, libc::F_FULLFSYNC) } #[cfg(not(any(target_os = "macos", target_os = "ios")))] unsafe fn os_fsync(fd: c_int) -> c_int { libc::fsync(fd) } </ins> } pub fn datasync(&self) -> io::Result<()> {
Change:
When compiling this code with , I get an incorrect warning: The is used; removing it breaks the program. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Have you checked this on nightly? This looks like a duplicate of and it was fixed a couple of days ago.
Yes, this is with
Note that I need to add . No warning is shown without that flag.
I can reproduce on playground with as well:
I cannot reproduce the warning any more, it seems to be fixed. However, I am not sure if there is a testcase for that.
label: +E-needs-test Test could be to (which is the example above). The in can probably also be removed
claim
Unassigning because they told me that they don't have the time to do this.
claim

Discussion:
// ignore-wasm32-bare no libc to test ffi with // ignore-sgx no libc <ins> // Ensure no false positive on "unused extern crate" lint #![deny(unused_extern_crates)] </ins> #![feature(rustc_private)] extern crate libc;
Change:
does not build on the current nightly because the compiler is unable to infer that a type is . This is a regression in the latest nightly. The line that errors is . Error message: Relevant commits: cc rust-lang-nursery/futures-rs
Minimized example without and external dependencies: .
Possibly caused by cc
Enabling the feature fixes this, so this is being caused by the gate .
Perhaps do I need some normalization before doing deferred ness checking?
triage. This is now a stable-to-beta regression. P-high.
assigning to to either r+ PR , come up with a new fix, or delegate those options to someone else.

Discussion:
fcx.resolve_generator_interiors(def_id); for (ty, span, code) in fcx.deferred_sized_obligations.borrow_mut().drain(..) { <ins> let ty = fcx.normalize_ty(span, ty); </ins> fcx.require_type_is_sized(ty, span, code); } fcx.select_all_obligations_or_error();

// // to work in stable even if the Sized bound on `drop` is relaxed. for i in 0..fn_sig.inputs().skip_binder().len() { <del> let input = tcx.erase_late_bound_regions(&fn_sig.input(i)); </del> <ins> // We just want to check sizedness, so instead of introducing // placeholder lifetimes with probing, we just replace higher lifetimes // with fresh vars. let input = self.replace_bound_vars_with_fresh_vars( expr.span, infer::LateBoundRegionConversionTime::FnCall, &fn_sig.input(i)).0; </ins> self.require_type_is_sized_deferred(input, expr.span, traits::SizedArgumentType); }

// Here we want to prevent struct constructors from returning unsized types. // There were two cases this happened: fn pointer coercion in stable // and usual function call in presense of unsized_locals. <del> let output = tcx.erase_late_bound_regions(&fn_sig.output()); </del> <ins> // Also, as we just want to check sizedness, instead of introducing // placeholder lifetimes with probing, we just replace higher lifetimes // with fresh vars. let output = self.replace_bound_vars_with_fresh_vars( expr.span, infer::LateBoundRegionConversionTime::FnCall, &fn_sig.output()).0; </ins> self.require_type_is_sized_deferred(output, expr.span, traits::SizedReturnType); }

<ins> use std::ops::Deref; fn foo<P>(_value: <P as Deref>::Target) where P: Deref, <P as Deref>::Target: Sized, {} fn main() { foo::<Box<u32>>(2); } </ins>
Change:
Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?

Discussion:
/// ``` ``` <ins> As of version 1.34.0, one can also omit the `fn main()`, but you will have to disambiguate the error type: ```ignore /// ``` /// use std::io; /// let mut input = String::new(); /// io::stdin().read_line(&mut input)?; /// # Ok::<(), io:Error>(()) /// ``` ``` This is an unfortunate consequence of the `?` operator adding an implicit conversion, so type inference fails because the type is not unique. Please note that you must write the `(())` in one sequence without intermediate whitespace so that rustdoc understands you want an implicit `Result`-returning function. </ins> ## Documenting macros Here’s an example of documenting a macro:

} } <del> if dont_insert_main || already_has_main { </del> <ins> // FIXME: This code cannot yet handle no_std test cases yet if dont_insert_main || already_has_main || prog.contains("![no_std]") { </ins> prog.push_str(everything_else); } else { <del> prog.push_str("fn main() {n"); </del> <ins> let returns_result = everything_else.trim_end().ends_with("(())"); let (main_pre, main_post) = if returns_result { ("fn main() { fn _inner() -> Result<(), impl core::fmt::Debug> {", "}n_inner().unwrap() }") } else { ("fn main() {n", "n}") }; prog.extend([main_pre, everything_else, main_post].iter().cloned()); </ins> line_offset += 1; <del> prog.push_str(everything_else); prog.push_str("n}"); </del> } debug!("final doctest:n{}", prog);

<ins> // compile-flags:--test /// A check of using various process termination strategies /// /// # Examples /// /// ```rust /// assert!(true); // this returns `()`, all is well /// ``` /// /// You can also simply return `Ok(())`, but you'll need to disambiguate the /// type using turbofish, because we cannot infer the type: /// /// ```rust /// Ok::<(), &'static str>(()) /// ``` /// /// You can err with anything that implements `Debug`: /// /// ```rust,should_panic /// Err("This is returned from `main`, leading to panic")?; /// Ok::<(), &'static str>(()) /// ``` pub fn check_process_termination() {} </ins>
Change:
Implemented in as .
Updated from: to: in . Thanks
Seems straightforward enough to me. fcp 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 none object), 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.
Question: We have , should we have as well?
We could, but that’s going quickly into diminishing returns IMO. You can always use something like

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(ptr_hash)] </del> /// use std::collections::hash_map::DefaultHasher; /// use std::hash::{Hash, Hasher}; /// use std::ptr;

/// /// assert_eq!(actual, expected); /// ``` <del> #[unstable(feature = "ptr_hash", reason = "newly added", issue = "56286")] </del> <ins> #[stable(feature = "ptr_hash", since = "1.35.0")] </ins> pub fn hash<T: ?Sized, S: hash::Hasher>(hashee: *const T, into: &mut S) { use hash::Hash; hashee.hash(into);
Change:
See the following extreme test-case: This is what godbolt says rust stable does with it with -O: That is, it allocates 1024 bytes (expected), writes directly at the allocated location, and then proceeds to copy 1016 (uninitialized) bytes from the stack.
Similar to , but not quite the same issue.
Looks resolved around 1.52
label: +E-needs-test -A-LLVM (~ already has the optimization and as I understand that hasn't been touched by LLVM's optimizer yet. So it isn't LLVM-specific, right?~)

Discussion:
<del> // compile-flags: -O #![crate_type = "lib"] use std::mem::MaybeUninit; // Boxing a `MaybeUninit` value should not copy junk from the stack #[no_mangle] pub fn box_uninitialized() -> Box<MaybeUninit<usize>> { // CHECK-LABEL: @box_uninitialized // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably. // CHECK: declare {{(dso_local )?}}noalias noundef ptr @__rust_alloc(i{{[0-9]+}} noundef, i{{[0-9]+}} allocalign noundef) unnamed_addr [[RUST_ALLOC_ATTRS:#[0-9]+]] // CHECK-DAG: attributes [[RUST_ALLOC_ATTRS]] = { {{.*}} allockind("alloc,uninitialized,aligned") allocsize(0) {{(uwtable )?}}"alloc-family"="__rust_alloc" {{.*}} } </del>

<ins> // compile-flags: -O #![crate_type = "lib"] use std::mem::MaybeUninit; // Boxing a `MaybeUninit` value should not copy junk from the stack #[no_mangle] pub fn box_uninitialized() -> Box<MaybeUninit<usize>> { // CHECK-LABEL: @box_uninitialized // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } #[repr(align(1024))] pub struct LotsaPadding(usize); // Boxing a value with padding should not copy junk from the stack #[no_mangle] pub fn box_lotsa_padding() -> Box<LotsaPadding> { // CHECK-LABEL: @box_lotsa_padding // CHECK-NOT: alloca // CHECK-NOT: getelementptr // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(LotsaPadding(42)) } // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably. // CHECK: declare {{(dso_local )?}}noalias noundef ptr @__rust_alloc(i{{[0-9]+}} noundef, i{{[0-9]+}} allocalign noundef) unnamed_addr [[RUST_ALLOC_ATTRS:#[0-9]+]] // CHECK-DAG: attributes [[RUST_ALLOC_ATTRS]] = { {{.*}} allockind("alloc,uninitialized,aligned") allocsize(0) {{(uwtable )?}}"alloc-family"="__rust_alloc" {{.*}} } </ins>
Change:
Example: Behavior is observable on stable and nightly. Clearly can be shortened to just .
This is a problem with how the struct is represented when re-exporting from a different crate. For example, : The gets converted into a where clause in the re-export, but i'm not sure what introduces the duplicate lifetime bound.
Current documentation still has evidence of this bug: see e.g. in

Discussion:
use std::fmt; use rustc::hir::def_id::DefId; <ins> use rustc::util::nodemap::FxHashSet; </ins> use rustc_target::spec::abi::Abi; use rustc::hir;

impl<'a> fmt::Display for GenericBounds<'a> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <ins> let mut bounds_dup = FxHashSet::default(); </ins> let &GenericBounds(bounds) = self; <del> for (i, bound) in bounds.iter().enumerate() { </del> <ins> for (i, bound) in bounds.iter().filter(|b| bounds_dup.insert(b.to_string())).enumerate() { </ins> if i > 0 { f.write_str(" + ")?; }

clause.push_str(&format!("{}: {}", ty, GenericBounds(bounds))); } } <del> &clean::WherePredicate::RegionPredicate { ref lifetime, ref bounds } => { clause.push_str(&format!("{}: ", lifetime)); for (i, lifetime) in bounds.iter().enumerate() { if i > 0 { clause.push_str(" + "); } clause.push_str(&lifetime.to_string()); } </del> <ins> &clean::WherePredicate::RegionPredicate { ref lifetime, ref bounds } => { clause.push_str(&format!("{}: {}", lifetime, bounds.iter() .map(|b| b.to_string()) .collect::<Vec<_>>() .join(" + "))); </ins> } &clean::WherePredicate::EqPredicate { ref lhs, ref rhs } => { if f.alternate() {
Change:
gives this warning : However, applying such changes gives these errors : I think the warning should be replaced with something that works (like ) or not issued at all.
CC , we need to extend to closure args too .

Discussion:
let body = ir.tcx.hir().body(body_id); for arg in &body.arguments { <ins> let is_shorthand = match arg.pat.node { crate::hir::PatKind::Struct(..) => true, _ => false, }; </ins> arg.pat.each_binding(|_bm, hir_id, _x, ident| { debug!("adding argument {:?}", hir_id); <del> fn_maps.add_variable(Arg(hir_id, ident.name)); </del> <ins> let var = if is_shorthand { Local(LocalInfo { id: hir_id, name: ident.name, is_shorthand: true, }) } else { Arg(hir_id, ident.name) }; fn_maps.add_variable(var); </ins> }) };

<ins> #![deny(unused_variables)] struct Point { x: i32, y: i32, } fn main() { let points = vec!(Point { x: 1, y: 2 }, Point { x: 3, y: 4 }); let _: i32 = points.iter() .map(|Point { x, y }| y) //~^ ERROR unused variable .sum(); let _: i32 = points.iter() .map(|x| 4) //~^ ERROR unused variable .sum(); } </ins>

<ins> error: unused variable: `x` --> $DIR/unused-closure-argument.rs:12:23 | LL |         .map(|Point { x, y }| y) |                       ^ help: try ignoring the field: `x: _` | note: lint level defined here --> $DIR/unused-closure-argument.rs:1:9 | LL | #![deny(unused_variables)] |         ^^^^^^^^^^^^^^^^ error: unused variable: `x` --> $DIR/unused-closure-argument.rs:17:15 | LL |         .map(|x| 4) |               ^ help: consider prefixing with an underscore: `_x` error: aborting due to 2 previous errors </ins>
Change:
The simdnoise crate with an LLVM assertion: This is not a regression, it's confirmed to also fail on 1.28.0 (alt builds are not available past that).
Wow, this one's amazing.
This one still reproduces on master.
Unfortunately, I wasn't able to get this to assert with and a separate invocation.
Can an absolute beginner take this one?Let me know if someone is working on this already
This is an assertion failure in the very depths of LLVM's machine code backend, you can try to find a minimal test case if you want, but I wouldn't recommend finding or fixing the actual bug to a beginner (but feel free to try if you feel very ambitious!). You can also try your hand at one of the issues, which are specifically meant for beginners.
Did you use an assertion-enabled build? I tried again just now and am still seeing the assertion:
my bad, new nightly builds don't have llvm assertions enabled.

Discussion:
<del> Subproject commit 777efaf5644706b36706a7a5c51edb63835e05ca </del> <ins> Subproject commit f1ed22803f09e3b2c2b86d773db07ce70804987a </ins>
Change:
I'm trying to pass multiple conditionally downstream. However, despite +/- for adding/removing a feature it appears only the last value takes effect.
FWIW, you can check for values without any test program like: $ rustc --print cfg -C target-feature=+avx2 -C target-feature=+fma $ rustc --print cfg -C target-feature=+avx2,+fma
I agree that it's a bug and will try to fix it.
Fixed in

Discussion:
Individual targets will support different features; this flag lets you control enabling or disabling a feature. Each feature should be prefixed with a `+` to <del> enable it or `-` to disable it. Separate multiple features with commas. </del> <ins> enable it or `-` to disable it. Features from multiple `-C target-feature` options are combined.  Multiple features can be specified in a single option by separating them with commas - `-C target-feature=+x,-y`.  If some feature is specified more than once with both `+` and `-`, then values passed later override values passed earlier.  For example, `-C target-feature=+x,-y,+z -Ctarget-feature=-x,+y` is equivalent to `-C target-feature=-x,+y,+z`. </ins> To see the valid options and an example of use, run `rustc --print target-features`.

"one of supported relocation models (`rustc --print relocation-models`)"; pub const parse_tls_model: &str = "one of supported TLS models (`rustc --print tls-models`)"; <ins> pub const parse_target_feature: &str = parse_string; </ins> } #[allow(dead_code)]

} true } <ins> fn parse_target_feature(slot: &mut String, v: Option<&str>) -> bool { match v { Some(s) => { if !slot.is_empty() { slot.push_str(","); } slot.push_str(s); true } None => false, } } </ins> } ) }

"use soft float ABI (*eabihf targets only) (default: no)"), target_cpu: Option<String> = (None, parse_opt_string, [TRACKED], "select target processor (`rustc --print target-cpus` for details)"), <del> target_feature: String = (String::new(), parse_string, [TRACKED], </del> <ins> target_feature: String = (String::new(), parse_target_feature, [TRACKED], </ins> "target specific attributes. (`rustc --print target-features` for details).  This feature is unsafe."),

<ins> // only-x86_64 // compile-flags: -C target-feature=+sse2,-avx,+avx2 -C target-feature=+avx,-avx2 #![crate_type = "lib"] #[no_mangle] pub fn foo() { // CHECK: attributes #0 = { {{.*}}"target-features"="+sse2,-avx,+avx2,+avx,-avx2"{{.*}} } } </ins>