jiebi/CodeConvo huggingface dataset:
Code change:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

Related discussion:
text: self.fold_item_recur(item) } } <ins> enum CodeBlockInvalid { SyntaxError, Empty, } </ins>
Code change:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

Related discussion:
text: /// _ #[doc = "```"] pub fn crazy_attrs() {} <ins> /// ```rust /// ``` pub fn empty_rust() {} /// ``` /// /// /// ``` pub fn empty_rust_with_whitespace() {} </ins>
Code change:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

Related discussion:
text: | = help: mark blocks that do not contain Rust code as text: ```text <ins> warning: Rust code block is empty --> $DIR/invalid-syntax.rs:68:5 | LL |   /// ```rust |  _____^ LL | | /// ``` | |_______^ warning: Rust code block is empty --> $DIR/invalid-syntax.rs:72:5 | LL |   /// ``` |  _____^ LL | | /// LL | | /// LL | | /// ``` | |_______^ help: mark blocks that do not contain Rust code as text | LL | /// ```text |     ^^^^^^^ </ins> error: unknown start of token:  --> <rustdoc-highlighting>:1:1 |
Code change:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

Related discussion:
text: #[cfg(not(test))] pub fn init() { <ins> // The standard streams might be closed on application startup. To prevent // std::io::{stdin, stdout,stderr} objects from using other unrelated file // resources opened later, we reopen standards streams when they are closed. unsafe { sanitize_standard_fds(); } </ins> // By default, some platforms will send a *signal* when an EPIPE error // would otherwise be delivered. This runtime doesn't install a SIGPIPE // handler, causing it to kill the program, which isn't exactly what we
Code change:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

Related discussion:
text: reset_sigpipe(); } <ins> // In the case when all file descriptors are open, the poll has been // observed to perform better than fcntl (on GNU/Linux). #[cfg(not(any( miri, target_os = "emscripten", target_os = "fuchsia", // The poll on Darwin doesn't set POLLNVAL for closed fds. target_os = "macos", target_os = "ios", target_os = "redox", )))] unsafe fn sanitize_standard_fds() { use crate::sys::os::errno; let pfds: &mut [_] = &mut [ libc::pollfd { fd: 0, events: 0, revents: 0 }, libc::pollfd { fd: 1, events: 0, revents: 0 }, libc::pollfd { fd: 2, events: 0, revents: 0 }, ]; while libc::poll(pfds.as_mut_ptr(), 3, 0) == -1 { if errno() == libc::EINTR { continue; } libc::abort(); } for pfd in pfds { if pfd.revents & libc::POLLNVAL == 0 { continue; } if libc::open("/dev/null0".as_ptr().cast(), libc::O_RDWR, 0) == -1 { // If the stream is closed but we failed to reopen it, abort the // process. Otherwise we wouldn't preserve the safety of // operations on the corresponding Rust object Stdin, Stdout, or // Stderr. libc::abort(); } } } #[cfg(any(target_os = "macos", target_os = "ios", target_os = "redox"))] unsafe fn sanitize_standard_fds() { use crate::sys::os::errno; for fd in 0..3 { if libc::fcntl(fd, libc::F_GETFD) == -1 && errno() == libc::EBADF { if libc::open("/dev/null0".as_ptr().cast(), libc::O_RDWR, 0) == -1 { libc::abort(); } } } } #[cfg(any( // The standard fds are always available in Miri. miri, target_os = "emscripten", target_os = "fuchsia"))] unsafe fn sanitize_standard_fds() {} </ins> #[cfg(not(any(target_os = "emscripten", target_os = "fuchsia")))] unsafe fn reset_sigpipe() { assert!(signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR);
Code change:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

Related discussion:
text: return r } <ins> #[cfg(unix)] fn assert_fd_is_valid(fd: libc::c_int) { if unsafe { libc::fcntl(fd, libc::F_GETFD) == -1 } { panic!("file descriptor {} is not valid: {}", fd, io::Error::last_os_error()); } } #[cfg(windows)] fn assert_fd_is_valid(_fd: libc::c_int) {} </ins> #[cfg(windows)] unsafe fn without_stdio<R, F: FnOnce() -> R>(f: F) -> R { type DWORD = u32;
Code change:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

Related discussion:
text: fn main() { if env::args().len() > 1 { <ins> // Writing to stdout & stderr should not panic. </ins> println!("test"); assert!(io::stdout().write(b"testn").is_ok()); assert!(io::stderr().write(b"testn").is_ok()); <ins> // Stdin should be at EOF. </ins> assert_eq!(io::stdin().read(&mut [0; 10]).unwrap(), 0); <ins> // Standard file descriptors should be valid on UNIX: assert_fd_is_valid(0); assert_fd_is_valid(1); assert_fd_is_valid(2); </ins> return }
Code change:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

Related discussion:
text: .stdout(Stdio::null()) .stderr(Stdio::null()) .status().unwrap(); <del> assert!(status.success(), "{:?} isn't a success", status); </del> <ins> assert!(status.success(), "{} isn't a success", status); </ins> // Finally, close everything then spawn a child to make sure everything is // *still* ok. let status = unsafe { without_stdio(|| Command::new(&me).arg("next").status()) }.unwrap(); <del> assert!(status.success(), "{:?} isn't a success", status); </del> <ins> assert!(status.success(), "{} isn't a success", status); </ins> }
Code change:
only checks that the link section contains no pointers, but there may be arbitrary bytes in the data, even undefined bytes (e.g. due to padding). cc is that ok? llvm may insert whereever there are undefined bytes. Or should we lint/error on such statics? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
that should be ok yeah, I think that's what happens on all other platforms and it's up to the consumer to ensure that all bytes they read have defined values if they want.
Ok, I guess we should probably just document that in the code segment that I linked above.
claim

Related discussion:
text: return } <del> // For the wasm32 target statics with #[link_section] are placed into custom </del> <ins> // For the wasm32 target statics with `#[link_section]` are placed into custom </ins> // sections of the final output file, but this isn't link custom sections of // other executable formats. Namely we can only embed a list of bytes, // nothing with pointers to anything else or relocations. If any relocation // show up, reject them here. <ins> // `#[link_section]` may contain arbitrary, or even undefined bytes, but it is // the consumer's responsibility to ensure all bytes that have been read // have defined values. </ins> let instance = ty::Instance::mono(tcx, id); let cid = GlobalId { instance,
Code change:
The following code (which is awesome!), but the warning is not as clear as it could be: This results in: it should probably say "futures do nothing unless you await them" or something. Most people won't know what 'polled' is all about, I think.
The current note originates from: To change it, simply edit that.
What about ?
In any case, . Just a typo :wink: I would actually expect something in the line of: Btw, I'd love to work on this issue and provide a PR. I'm really looking forward to help Rust just as much as it has helped me thus far!
We may want to work in the fact that you can use somehow. Other than that, sounds pretty good.
what trait does provide ? :astonished:
is equivalent to and is likely to replace it eventually. See I think for now might be good enough and we could tweak later.
That makes sense to me! Am I ok to work on this?

Related discussion:
text: /// When using a future, you generally won't call `poll` directly, but instead /// `await!` the value. #[doc(spotlight)] <del> #[must_use = "futures do nothing unless polled"] </del> <ins> #[must_use = "futures do nothing unless you `.await` or poll them"] </ins> #[stable(feature = "futures_api", since = "1.36.0")] pub trait Future { /// The type of value produced on completion.
Code change:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!

Related discussion:
text: <ins> // compile-flags: --edition=2018 pub use u32; </ins>
Code change:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!

Related discussion:
text: <ins> // Regression test for #60976: ICE (with <=1.36.0) when another file had `use <primitive_type>;`. // check-pass // aux-build:extern-use-primitive-type-lib.rs extern crate extern_use_primitive_type_lib; fn main() {} </ins>
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: use rustc::hir::def::{Res, DefKind}; use rustc::hir::def_id::DefId; use rustc::lint; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::adjustment; use rustc_data_structures::fx::FxHashMap; use lint::{LateContext, EarlyContext, LintContext, LintArray};
Code change:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

Related discussion:
text: return; } <del> let t = cx.tables.expr_ty(&expr); let type_permits_lack_of_use = if t.is_unit() || cx.tcx.is_ty_uninhabited_from( cx.tcx.hir().get_module_parent_by_hir_id(expr.hir_id), t) { true } else { match t.sty { ty::Adt(def, _) => check_must_use(cx, def.did, s.span, "", ""), ty::Opaque(def, _) => { let mut must_use = false; for (predicate, _) in &cx.tcx.predicates_of(def).predicates { if let ty::Predicate::Trait(ref poly_trait_predicate) = predicate { let trait_ref = poly_trait_predicate.skip_binder().trait_ref; if check_must_use(cx, trait_ref.def_id, s.span, "implementer of ", "") { must_use = true; break; } } } must_use } ty::Dynamic(binder, _) => { let mut must_use = false; for predicate in binder.skip_binder().iter() { if let ty::ExistentialPredicate::Trait(ref trait_ref) = predicate { if check_must_use(cx, trait_ref.def_id, s.span, "", " trait object") { must_use = true; break; } } } must_use } _ => false, } }; </del> <ins> let ty = cx.tables.expr_ty(&expr); let type_permits_lack_of_use = check_must_use_ty(cx, ty, &expr, s.span, ""); </ins> let mut fn_warned = false; let mut op_warned = false;