jiebi/CodeConvo huggingface dataset:
Change:
None, ) }; <ins> let status = if status == c::STATUS_PENDING { unsafe { c::WaitForSingleObject(self.as_raw_handle(), c::INFINITE) }; io_status.status() } else { status }; </ins> match status { // If the operation has not completed then abort the process. // Doing otherwise means that the buffer may be read and the stack // written to after this function returns. <del> c::STATUS_PENDING => { rtabort!("I/O error: operation failed to complete synchronously"); } </del> <ins> c::STATUS_PENDING => rtabort!("I/O error: operation failed to complete synchronously"), </ins> // Success! status if c::nt_success(status) => Ok(io_status.Information),

Discussion:
on windows. with and rename it back to git bash I expected to see this happen: my really long string gets printed twice, followed by a clean exit Instead, this happened: some amount of my really long string gets printed, followed by: The test case, while simple, does appear to have a minimum size requirement to trigger this crash. Shrinking the string will cause it to stop crashing. I'm using in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too. Redirecting to a file instead of a pipe seems to not trigger this crash. Using is not necessary to trigger the crash, running the built executable directly also crashes. This PR this new error condition: I am not the only one seeing this new error message: modify labels: +regression-from-stable-to-stable +O-windows
I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with . In my original bug report, I suggested calling once if returned , since that will at least resolve the pending IO correctly in the case where the file is not being used for other IOs concurrently. This would cover this and other cases at least as well as the original code calling . This isn't perfect, since of course takes , so you can probably deadlock in a multi-threaded process in this async pipe configuration. But it would at least avoid the common case. However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped?
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap.
Thanks for fixing the issue quickly. When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? Or will we have to wait for a fix in 1.63?
PR was nominated and accepted for both beta and stable backport by T-libs. Leaving this open until those play out. Assigning P-high for the same reasons it was accepted for backports.
Change:
let (adjustments, _) = self.register_infer_ok_obligations(ok); self.apply_adjustments(expr, adjustments); <del> Ok(target) </del> <ins> Ok(if expr_ty.references_error() { self.tcx.types.err } else { target }) </ins> } /// Same as `try_coerce()`, but without side-effects.

Discussion:
Because of the method error, doesn't get a type (not even , AFAICT), and then it gets inferred to from another call in the function, which results in the unsized variable error.
cc
I'd expect a simple fix for this would be to actually set as 's type, so it can't be inferred to anything else, although that could make other errors less informative.
I just spent a lot of time looking at a error. The errors were hidden by a couple of screens of "doc comment not used by rustdoc" warnings. Because was unknown, the compiler assumed it implemented no traits at all, leading to misleading errors below and user confusion: "why isn't it when this other similar type similar is?", "how can I find out if a type is " and so on. I don't know if works like that, but in this case it might be better to assume that the type implements any trait it's required to.
That doesn't really work out, since the issue here is that inference gets a free pass instead of inferring which would at least signal anything. The fix seems simple, I really don't know why I haven't tried it yet
I'm not saying that the type should be inferred to something else from the code below (like you said it was happening in the issue description) -- that seems bad. But on the other hand the compiler should probably not report an error every place the type or variable is used.
I just reread, and: That's not relevant here - the problem is inference flows up into the variable, which is correct in other cases but in this case it infers the slice type which is unsized. The error is a mere side-effect.
The underlying cause is that we have two maps for →, a general one and one for locals. When type checking we write to the general one but the one for locals is only written to once, during initialization, and the we read from it. If we kept it up to date or read from the general map, the knock-down error wouldn't appear.
Change:
/// Registers a custom allocation error hook, replacing any that was previously registered. /// <del> /// The allocation error hook is invoked when an infallible memory allocation fails, before /// the runtime aborts. The default hook prints a message to standard error, /// but this behavior can be customized with the [`set_alloc_error_hook`] and /// [`take_alloc_error_hook`] functions. </del> <ins> /// The allocation error hook is invoked when an infallible memory allocation fails — that is, /// as a consequence of calling [`handle_alloc_error`] — before the runtime aborts. </ins> /// <del> /// The hook is provided with a `Layout` struct which contains information </del> <ins> /// The allocation error hook is a global resource. [`take_alloc_error_hook`] may be used to /// retrieve a previously registered hook and wrap or discard it. /// /// # What the provided `hook` function should expect /// /// The hook function is provided with a [`Layout`] struct which contains information </ins> /// about the allocation that failed. /// <del> /// The allocation error hook is a global resource. </del> <ins> /// The hook function may choose to panic or abort; in the event that it returns normally, this /// will cause an immediate abort. /// /// Since [`take_alloc_error_hook`] is a safe function that allows retrieving the hook, the hook /// function must be _sound_ to call even if no memory allocations were attempted. /// /// # The default hook /// /// The default hook, used if [`set_alloc_error_hook`] is never called, prints a message to /// standard error (and then returns, causing the runtime to abort the process). /// Compiler options may cause it to panic instead, and the default behavior may be changed /// to panicking in future versions of Rust. </ins> /// /// # Examples ///

Discussion:
's documentation says: However, is also specified to call the hook set with (unstable) which per its example is permitted to panic and thereby potentially unwind, and , a “likely” future version of might choose to panic on allocation failure instead. Therefore, the documentation should be changed to not imply that this function will always abort, which could be taken as a promise that it will never unwind. It also might be useful to expand the documentation of so that the text and not only the example code specifies that it's okay to unwind from the hook (and what happens if you don't). (See also which is broader but doesn't mention this aspect.) cc from label +A-allocators +T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
removed, see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information <ins> --html-no-source Disable HTML source code pages generation </ins> @path               Read newline separated options from `path`

Discussion:
Kind of related to and the  attribute. The behaviour would be the same as the latter but wouldn't require any source code changes. My use-case here is to generate docs on the CI and reduce the size (400MB just for docs for each version is a bit much), but if people want to generate docs locally they should still be able to get the source code pages if they want. suggested to create an issue for this.
To reduce the global documentation size, I suggested in to group items that don't have impls by kinds. Would require an RFC though. In any case, I think it's a good idea to add an option to have this done in the command line.
Change:
NO_DEBUG_ASSERTIONS=1 os: osx osx_image: xcode7.3 <del> if: branch = disabled </del> <ins> if: branch = auto </ins> - env: > RUST_CHECK_TARGET=dist

Discussion:
Happened for these PRs so far:
Thanks for the report. This is a Travis CI issue, currently tracked in travis-ci/travis-ci. A temporary workaround that disables all Xcode 7.3 () is currently testing.
Change:
<ins> error: function pointer types may not have generic parameters --> $DIR/issue-107998.rs:3:18 | LL | fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { |                  ^^^^ | help: consider moving the lifetime parameter to a `for` parameter list | LL - fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { LL + fn with<R>(f: &for<'a> fn(x: &'a i32) -> R) -> R { | error: lifetime parameter `'a` only used once --> $DIR/issue-107998.rs:3:19 | LL | fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { |                   ^^      --- |                   |       | |                   |       ...is used only here |                   |       help: elide the single-use lifetime |                   this lifetime... | note: the lint level is defined here --> $DIR/issue-107998.rs:1:9 | LL | #![deny(single_use_lifetimes)] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
<!-- 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. --: Needs a rustc built with debug assertions, <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<ins> error: expected expression, found `;` --> $DIR/issue-109237.rs:2:12 | LL |     () => {;}; |            ^ expected expression ... LL |     let _ = statement!(); |             ------------ in this macro invocation | = note: the macro call doesn't expand to an expression, but it can expand to a statement = note: this error originates in the macro `statement` (in Nightly builds, run with -Z macro-backtrace for more info) help: surround the macro invocation with `{}` to interpret the expansion as a statement | LL |     let _ = { statement!(); }; |             ~~~~~~~~~~~~~~~~~ error: aborting due to previous error </ins>

Discussion:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
warning: unnecessary parentheses around assigned value <del> --> $DIR/suggestions.rs:59:21 </del> <ins> --> $DIR/suggestions.rs:59:31 </ins> | <del> LL |         let mut a = (1); |                     ^^^ help: remove these parentheses </del> <ins> LL |         let mut registry_no = (format!("NX-{}", 74205)); |                               ^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses </ins> | note: lint level defined here --> $DIR/suggestions.rs:13:21

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.
Change:
<ins> //@ build-pass // Regression test for an overly aggressive assertion in #130855. fn main() { let subtype: &(dyn for<'a> Fn(&'a i32) -> &'a i32) = &|x| x; let supertype: &(dyn Fn(&'static i32) -> &'static i32) = subtype; } </ins>

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/107995>. #![crate_name = "foo"] // @has 'foo/fn.foo.html' // @has - '//*[@class="docblock"]//a[@href="fn.bar.html"]' 'bar`' /// A foo, see also [ bar`] pub fn foo() {} // @has 'foo/fn.bar.html' // @has - '//*[@class="docblock"]' 'line Path line' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' #[doc = "line ["] #[doc = "Path"] #[doc = "] line"] pub fn bar() {} // @has 'foo/fn.another.html' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' /// [ `Path`] pub fn another() {} // @has 'foo/fn.last.html' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' /// [ Path`] pub fn last() {} pub struct Path; </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summarycargo bisect-rustc points </summarysearched nightlies: from nightly-2023-01-30 to nightly-2023-02-13 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: </details label +regression-from-stable-to-nightly +T-rustdoc
cc as author of
Duplicate of
I have a similar problem. Steps to reproduce:
Same issue also reproduces when is documented directly, not as a dependency.
The link in looks like this , not the single backtick and also whitespace. Looks like a mismatch in preprocessing the stuff inside between rustc and rustdoc.
link , extra whitespace.
Oh, yes, this reproduces:
There's still something else going on since AFAICT there are no links in case of
link , extra newlines (?) after the doc strings are merged.
Oh, I was looking at the wrong macro, sorry. :man_facepalming:
I'll try to fix all this stuff tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Fixed in
Change:
<ins> // check-pass // aux-build:issue-79825.rs #![feature(trait_alias)] extern crate issue_79825; #[issue_79825::assert_input] trait Alias = Sized; fn main() {} </ins>

Discussion:
I tried this code: I expected the code to compile sucessfully, but got an ICE instead: (This is procedural-macro-related. I can't reproduce without a procedural macro.) This used to work and regressed in . <details<summaryBacktrace</summary<p</p</detailscc
If this code only works on nightly, then I don't think it's a . However, we don't have a label, so ...
This will be fixed by , which handles attributes on expressions in a more systematic way. As a side note, is currently parsed as
Do you want to add to that PR then?
We'll still need to add a regression test.
Assigning P-high as .20on.20nightly.20with.20.60stmt_ex.E2.80.A6) and removing I-prioritize.

I tried this code: and I expected to see this happen: the compiler complained was missing, or on nightly, after adding , compiled successfully, just like . Instead, this happened: the assertion failed. The compiler gave an empty as to the procedural macro: Edit: I found this in the compiler's log: I tried this with: nightly-2020-12-08 () nightly-2020-12-07 () beta () stable () cc
The pretty-print/reparse check has been removed, so this should hopefully be fixed on the latest nightly.
Confirmed that this is fixed in latest nightly, thanks! :heart: Do I need to leave this issue open (possibly for a regression test)?
That sounds like a good idea.
Change:
pub st_lspare: int32_t, pub st_birthtime: time_t, pub st_birthtime_nsec: c_long, <del> pub __unused: [uint8_t; 2], </del> <ins> pub __unused: [u8; 8], </ins> } #[repr(C)]

Discussion:
blksizet on 64-bit FreeBSD is 32 bits, not 64. on FreeBSD x8664 yields: yields: I tracked this down to the type definition, which is unconditionally 32-bit on FreeBSD (see , noting this line: this is unconditionally the definition of on FreeBSD - whether on 32-bit or 64-bit platform.)
Also, is a no-op (two fields of size 0) on 64-bit FreeBSD, the field can be deleted from the structure.
Change:
<ins> #![feature(const_generics)] //~^ ERROR features `const_generics` and `min_const_generics` are incompatible #![allow(incomplete_features)] #![feature(min_const_generics)] fn main() {} </ins>

Discussion:
I expect the code below code to compile, but it fails. should allow more than just the types whitelisted in , but it seems rustc only looks at the flag in this case. The error message is:
You are right But why would you want to use the two of them?
I imagine this to happen whenever at first you only decide to use , but then later also switch to . You might just follow rustc, which tells you to add to your project, so you do, but then you get the behaviour as described in this issue. This could also perhaps get triggered in a more subtle way where you write a library that uses to enable or disable features.
what do you think ?
It probably makes sense to instead check if we are not using here, but there are a quite a few places were we check for , we maybe want to instead emit an error/warning when using both and in the same crate.
Created a way to produce an error in case of incompatible features, like this one
I have one question, how does using 'incompatible feature' cause maybe undefined behavior? Are there other incompatible features? In this case, wouldn't it be better to produce an error message like "feature(constgenerics) is a superset of feature(minconst_generics)"?
Note that: results in a : So currently is not a superset of .
You are missing a in your feature. I still think constgenerics are a superset of minconstgenerics, but rustc just suggest using the smaller one in this case becouse that's the subset aiming to be stabilized for now
Ah of course, my bad I was confused looking at some ui tests for const generics, and missed that those now have support differentiating between expected behavior under and , and thought a particular error was always being thrown, instead of only under .
Change:
} let mut timeout = c::timeval { <del> tv_sec: timeout.as_secs() as c_long, </del> <ins> tv_sec: cmp::min(timeout.as_secs(), c_long::MAX as u64) as c_long, </ins> tv_usec: (timeout.subsec_nanos() / 1000) as c_long, };

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Hello! :wave: I tried this code on Windows: I expected to see this happen: Success for an available address like and blocking forever (or until TCP timeout) for just like on Linux. Instead, this happened: the call never succeeds, not even for on Windows. Related: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Thanks for the report! My best guess from quickly glancing at the code is that the problem is here: This is using to convert seconds into an (aka ). Which means that it can become a negative timeout. If I'm right then the fix here would be to limit the timeout to or less.
claim
thanks for your work on this and pushing it over the finish line! :+1: :pray:
Change:
--> $DIR/issue-88621.rs:9:13 | LL |     let _ = Kind2::Foo() as u8; <del> |             ^^^^^^^^^^^^^^^^^^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object </del> <ins> |             ^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less | = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information </ins> error: aborting due to 1 previous error

Discussion:
Possibly link to the Rust Reference where this is explained in detail. Casting an enum to an int is common for C developers. When I searched the internet for guides on how to do this in Rust, they all essentially said it just works like . E.g. , . These guides don't explicitly say that this only works if all of the enum variants are unit-like. The compiler message in this situation did not help me to understand what had gone wrong, and googling for it and "enum" returned the same sort of results as mentioned above. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-newcomer-roadblock D-confusing
claim
Change:
mod find_use; <ins> #[derive(Debug)] </ins> pub(in crate::borrow_check) enum BorrowExplanation { UsedLater(LaterUseKind, Span), UsedLaterInLoop(LaterUseKind, Span),

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
osx_image: xcode8.2 install: &osx_install_sccache > travis_retry curl -o /usr/local/bin/sccache https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-16-sccache-x86_64-apple-darwin && <del> chmod +x /usr/local/bin/sccache </del> <ins> chmod +x /usr/local/bin/sccache && travis_retry curl -o /usr/local/bin/stamp https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror/2017-03-17-stamp-x86_64-apple-darwin && chmod +x /usr/local/bin/stamp </ins> - env: > RUST_CHECK_TARGET=check RUST_CONFIGURE_ARGS=--build=i686-apple-darwin

Discussion:
Often when debugging travis logs it's difficult to see how long everything is taking as we only time some steps, not all. Additionally there's not a lot of information to see how long it takes between steps. It'd be awesome if we had a tool where we basically wrapped the entire build () in a process that simply prepended all stdout/stderr messages with a relative timestamp. AppVeyor does this by default (has a timestamp for each log line message) but unfortunately Travis doesn't. Apparently which ends up looking like https://travis- which is basically exactly what we'd want.
You probably just want to use from moreutils for this. (This is what Julia does.)