jiebi/CodeConvo huggingface dataset:
Change:
}; // FIXME: We may want to elaborate here, though I assume this will be exceedingly rare. <ins> let mut return_ty = None; </ins> for bound in self.obligations_for_self_ty(return_vid) { if let Some(ret_projection) = bound.predicate.as_projection_clause() && let Some(ret_projection) = ret_projection.no_bound_vars() && self.tcx.is_lang_item(ret_projection.def_id(), LangItem::FutureOutput) { <del> let sig = projection.rebind(self.tcx.mk_fn_sig( input_tys, ret_projection.term.expect_type(), false, hir::Safety::Safe, Abi::Rust, )); return Some(ExpectedSig { cause_span, sig }); </del> <ins> return_ty = Some(ret_projection.term.expect_type()); break; </ins> } } <del> None </del> <ins> // SUBTLE: If we didn't find a `Future<Output = ...>` bound for the return // vid, we still want to attempt to provide inference guidance for the async // closure's arguments. Instantiate a new vid to plug into the output type. // // You may be wondering, what if it's higher-ranked? Well, given that we // found a type variable for the `FnOnce::Output` projection above, we know // that the output can't mention any of the vars. // // Also note that we use a fresh var here for the signature since the signature // records the output of the *future*, and `return_vid` above is the type // variable of the future, not its output. // // FIXME: We probably should store this signature inference output in a way // that does not misuse a `FnSig` type, but that can be done separately. let return_ty = return_ty.unwrap_or_else(|| self.next_ty_var(cause_span.unwrap_or(DUMMY_SP))); let sig = projection.rebind(self.tcx.mk_fn_sig( input_tys, return_ty, false, hir::Safety::Safe, Abi::Rust, )); return Some(ExpectedSig { cause_span, sig }); </ins> } fn sig_of_closure(

Discussion:
I'm writing this as a continuation of While the problem from first message in issue seems to be fixed, there are still cases when this fails. One of examples is when using instead of , when closure is expected to return : I expected to see this happen: All options used to work in past versions of rust Instead, this happened: Without explicit type hint it fails It most recently worked on: Not 100% sure, some explanations have been made in original issue
This is because the signature of  is: We only extract an async closure bound from cases where there is bound on the trait, which is not. There isn't even a supertrait bound that constrains the output type. I also do not expect this to ever be fixed, because that would require overly complicating the closure signature inference algorithm in ways that make me quite uncomfortable[^1][^2]. The correct solution is to rework the futures crate to have first-class async closure support, so for now I'd recommend just ascribing your type names. Sorry! [^1]: Firstly, this would break if another blanket implementation for were ever . [^2]: Secondly, the combinator shouldn't really be using bounds either -- it should be using bounds.
Alternatively, would fix this when paired with a slight adjustment to the closure signature inference that I'd be happy to make, but it seems like that PR is blocked.
Change:
int_impl! { i32, i32, u32, 32, 31, -2147483648, 2147483647, 8, "0x10000b3", "0xb301", "0x12345678", "0x78563412", "0x1e6a2c48", "[0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78]", "", "" } <del> widening_impl! { i32, i64, 32, signed } </del> } #[lang = "i64"]

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.
Change:
} pub struct ClashingExternDeclarations { <del> seen_decls: FxHashMap<Symbol, HirId>, </del> <ins> /// Map of function symbol name to the first-seen hir id for that symbol name.. If seen_decls /// contains an entry for key K, it means a symbol with name K has been seen by this lint and /// the symbol should be reported as a clashing declaration. // FIXME: Technically, we could just store a &'tcx str here without issue; however, the // `impl_lint_pass` macro doesn't currently support lints parametric over a lifetime. seen_decls: FxHashMap<String, HirId>, </ins> } /// Differentiate between whether the name for an extern decl came from the link_name attribute or

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. --Rustc 1.48.0 gives an incorrect warning about an external symbol being redeclared with a different signature, when the external symbols are in different namespaces. I tried this code: I expected to see this happen: Compile without warnings Instead, this happened: <!-- 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. --: The same behavior exists on nightly as well: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc would you be willing to help take a look at this? (it looks like you this way-back-when in ) On wasm targets there's which is why this should work but not actually generate a warning. Do you know if it's possible to call that logic perhaps? (would be able to consolidate "what's the name of this symbol" logic too!)
Sure thing! I'm currently in the process of moving, but will be able to get onto this on the weekend :) claim
No worries, and thanks! If you run out of time/steam I'm happy to look into this as well
Change:
var set_fragment = function(name) { if (browserSupportsHistoryApi()) { history.replaceState(null, null, "#" + name); <del> window.hashchange(); </del> <ins> highlightSourceLines(null); </ins> } else { location.replace("#" + name); }

Discussion:
When selecting Rust source code with either the latest stable or the latest nightly, the following is seen: e.g. see and try and select some lines Suspect that should be . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> fn main() { [9; [[9E; h]]]; //~^ ERROR: expected at least one digit in exponent //~| ERROR: cannot find value `h` in this scope [E0425] //~| ERROR: constant expression depends on a generic parameter } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
fn parse_block_tail(&mut self, lo: Span, s: BlockCheckMode) -> PResult<'a, P<Block>> { let mut stmts = vec![]; while !self.eat(&token::CloseDelim(token::Brace)) { <ins> if self.token == token::Eof { break; } </ins> let stmt = match self.parse_full_stmt(false) { Err(mut err) => { err.emit();

Discussion:
I tried this code: first outputs some error messages and then hangs up trying to allocate a large amount of memory. :
modify labels: regression-from-stable-to-nightly
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
Rust 1.34.0 and before is OK:
triage: P-medium. Removing nomination. Assigning to self and for initial investigation.
I'm seeing the same behavior on the following programs: and These were found with the help of .
Another program that I also observe to make run out of memory:
The original report is caused due to growing unbounded in a bad parser code path, in part due to it being a and not a (which it can't be at the moment). Now that I have a clue at what causes the behavior, I'll dig deeper for the trigger.
Change:
``` It’s important to be able to explicitly delineate code that may have bugs that <del> cause big problems. If a Rust program segfaults, you can be sure it’s somewhere in the sections marked `unsafe`. </del> <ins> cause big problems. If a Rust program segfaults, you can be sure the cause is related to something marked `unsafe`. </ins> # What does ‘safe’ mean?

Discussion:
But as far as I understand it, an unsafe block can instead break an invariant that causes a segfault further down the line in safe code. Also, stack overflows can cause a segfault.
You are correct in your understanding: the text could be tweaked to "you can be sure its cause is somewhere in the sections marked unsafe". NB. this is an implementation bug in rustc (), i.e. this doesn't happen in a "perfect" Rust compiler (the book is designed to document the language not the details of rustc).
This is not quite true:
The and disagree.
it depends what is meant by "cause"; a segfault will only occur if the program executes an block at some point, and does some unsafe operation with incorrect arguments, the point the nomicon and Ralf make is that the incorrectness in these arguments may flow from some safe piece of code. In any case, Steve's rewording is better than my proposal.
Change:
<ins> // compile-flags: -Zunpretty=hir // check-pass #![feature(let_else)] fn foo(x: Option<u32>) { let Some(_) = x else { panic!() }; } fn main() {} </ins>

Discussion:
Link to : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
It was probably regressed by , cc
label F-let-else
Change:
if let ty::Str = ty.kind { match (a.val, b.val) { <del> ( ConstValue::Slice { data: alloc_a, start: offset_a, end: end_a }, ConstValue::Slice { data: alloc_b, start: offset_b, end: end_b }, ) => { let len_a = end_a - offset_a; let len_b = end_b - offset_b; let a = alloc_a.get_bytes( &tcx, // invent a pointer, only the offset is relevant anyway Pointer::new(AllocId(0), Size::from_bytes(offset_a as u64)), Size::from_bytes(len_a as u64), ); let b = alloc_b.get_bytes( &tcx, // invent a pointer, only the offset is relevant anyway Pointer::new(AllocId(0), Size::from_bytes(offset_b as u64)), Size::from_bytes(len_b as u64), ); if let (Ok(a), Ok(b)) = (a, b) { return from_bool(a == b); } </del> <ins> (ConstValue::Slice { .. }, ConstValue::Slice { .. }) => { let a_bytes = get_slice_bytes(&tcx, a.val); let b_bytes = get_slice_bytes(&tcx, b.val); return from_bool(a_bytes == b_bytes); </ins> } _ => (), }

Discussion:
Results in cc
modify labels: I-ICE C-Bug T-compiler A-const-generics
I'm looking into this currently.
Partially as a note to myself and partially as an update to anyone interested The root cause of this bug seems to be the fact that we currently don't explicitly handle slice const values in , and therefore we always say they cannot match. This error eventually bubbles up to to produce all three errors.
Change:
<ins> warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> = note: `#[warn(bare_trait_objects)]` on by default help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: trait objects without an explicit `dyn` are deprecated --> $DIR/fresh-lifetime-from-bare-trait-obj-114664.rs:5:24 | LL | fn ice() -> impl AsRef<Fn(&())> { |                        ^^^^^^^ | = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html> help: use `dyn` | LL | fn ice() -> impl AsRef<dyn Fn(&())> { |                        +++ warning: 3 warnings emitted </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is not an RPITIT bug, for the record.
Change:
} #theme-choices > button:hover, #theme-choices > button:focus { <del> background-color: rgba(70, 70, 70, 0.33); </del> <ins> background-color: rgba(110, 110, 110, 0.33); </ins> } @media (max-width: 700px) {

Discussion:
! Note that "Ayu" is already highlighted, it happens to mdbook too. CC
The contrast is too small indeed. Want to send a fix?
I will pass on this, I sent too many pull requests today, I can do this maybe another day (a few days) or if anyone is interested can take up this task before I do.
I'll certainly send a PR tomorrow then.
Change:
<ins> // edition:2021 // ignore-tidy-linelength // Regression test for <https://github.com/rust-lang/rust/issues/101199> use std::future::Future; // @is "$.index[*][?(@.name=='get_int')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int')].inner.header.async" false pub fn get_int() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_async')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_async')].inner.header.async" true pub async fn get_int_async() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future')].inner.header.async" false pub fn get_int_future() -> impl Future<Output = i32> { async { 42 } } // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.header.async" true pub async fn get_int_future_async() -> impl Future<Output = i32> { async { 42 } } </ins>

Discussion:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.
Change:
impl<'a> MacResult for ParserAnyMacro<'a> { fn make_expr(self: Box<ParserAnyMacro<'a>>) -> Option<P<ast::Expr>> { let ret = panictry!(self.parser.borrow_mut().parse_expr()); <del> self.ensure_complete_parse(true); </del> <ins> self.ensure_complete_parse(true, "expression"); </ins> Some(ret) } fn make_pat(self: Box<ParserAnyMacro<'a>>) -> Option<P<ast::Pat>> { let ret = panictry!(self.parser.borrow_mut().parse_pat()); <del> self.ensure_complete_parse(false); </del> <ins> self.ensure_complete_parse(false, "pattern"); </ins> Some(ret) } fn make_items(self: Box<ParserAnyMacro<'a>>) -> Option<SmallVector<P<ast::Item>>> {

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
<ins> // Regression test for #88972. Used to cause a query cycle: //   optimized mir -> remove zsts -> layout of a generator -> optimized mir. // // edition:2018 // compile-flags: --crate-type=lib // build-pass pub async fn listen() -> Result<(), std::io::Error> { let f = do_async(); std::mem::forget(f); Ok(()) } pub async fn do_async() { listen().await.unwrap() } </ins>

Discussion:
Found by 1.56 crater -- https://crater- cc
Fixed by . Sorry for taking over, but since I started looking into it already.
Still needs a backport
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
fixed by
Change:
MirPhase::Runtime(RuntimePhase::Optimized), self.param_env, &callee_body, <ins> &caller_body, </ins> ) .is_empty() {

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
.current_dir(&dir); build.run(&mut cmd); build.run(Command::new("./configure") <ins> .args(&build.config.configure_args) </ins> .current_dir(&dir)); build.run(Command::new(build_helper::make(&build.config.build)) .arg("check")

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
compiler.host, target_compiler.host, target); <del> let libdir = build.sysroot_libdir(&target_compiler, target); let out_dir = build.cargo_out(&compiler, Mode::Librustc, target); add_to_sysroot(&out_dir, &libdir); </del> <ins> add_to_sysroot(&build.sysroot_libdir(target_compiler, target), &librustc_stamp(build, compiler, target)); </ins> } /// Cargo's output path for the standard library in a given stage, compiled

Discussion:
Rustbuild compiles the compiler in a particular location and is then responsible for copying artifacts over to the actual structure the compiler is expecting (e.g. rustbuild assembles a sysroot). In order to handle stale folders rustbuild , deduplicated by hash. This pretty obviously, though, doesn't work with multiple versions of the same library! We should probably call Cargo with and learn about compiled artifacts, that way we can copy precisely what we need to into the sysroot.