jiebi/CodeConvo huggingface dataset:
Change:
})) } <del> ty::Alias(..) | ty::Param(_) => None, </del> <ins> ty::Alias(..) | ty::Param(_) | ty::Placeholder(..) => None, </ins> ty::Infer(ty::TyVar(_)) => Ambiguous, <del> ty::Placeholder(..) | ty::Bound(..) | ty::Infer(ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_)) => { </del> <ins> // We can make this an ICE if/once we actually instantiate the trait obligation. ty::Bound(..) => None, ty::Infer(ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_)) => { </ins> bug!("asked to assemble builtin bounds of unexpected type: {:?}", self_ty); } }

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
I can't reproduce this? On master, that is.
Ah oops, looks like I minimized wrongly, give me a sec...
This should do: `
Minimized -- PR coming up.
Change:
use crate::io::{ self, ErrorKind, IntoInnerError, IoSlice, Seek, SeekFrom, Write, DEFAULT_BUF_SIZE, }; <del> use crate::mem; </del> <ins> use crate::mem::{self, ManuallyDrop}; </ins> use crate::ptr; /// Wraps a writer and buffers its output.

Discussion:
I tried this code: I expected to see this happen: it runs cleanly under Miri. Instead, this happened: The issue is in this construct: By the SB model, moving a (struct directly containing) retags that as the live unique owner of the referenced allocation. Thus passing to invalidates the duplicated () we just retrieved. The correct way to write this is with : Tested against 1.81.0-nightly (2024-07-09 ). This also catches , which is implemented using . IIRC the LLVM backend is currently not informed about this instance of this UB, as the relevant attributes are only when the argument passing ABI is or , which it is not in this case. Additionally, Miri's SB implementation does not complain when the box is , (conjecture: since is not ). cc — another case of instead of in std. This was randomly spotted. It might be worth it to do a grep for to try to spot further such mistakes. 's docs call this out as incorrect, but it's still quite easy to overlook.
Good catch! That is odd. Miri uses to determine the size to use for retags, so should not make a difference.
Just searched for using the GitHub search. The only other suspect snippet is already marked as kinda iffy: and somewhat amusingly calls out this exact issue in comments as well: The reason I assigned was conjecture based on likely old information (Miri only checking cases where we passed constant assertions to LLVM by default), but it is the observed behavior. The second potential reason now coming to mind is that is , thus getting raw pointer retags instead of unique retags.
Ah yes that would explain it.
I'm putting up a PR to fix just the instance reported here, but I would like to see a larger effort to replace all uses of .
In compiler, libs, or both? All usages of or just some particular ones?
Note that I am not a libs reviewer, so before you submit a large PR you should check in with one of these lovely people or post in Zulilp: I would prefer a simple policy that we do not use . All uses of it can (with varying amounts of typing) be replaced with . I don't think it's worth the brain cycles to try to think about whether a certain use of follows the pattern that was reported here.

The compiler is much less important here; nobody is running the compiler in Miri and this hazard is specific to an aspect of Stacked Borrows that is not actively used in optimizations the current toolchain does. For the library, being clean with respect to Stacked Borrows is an important quality-of-implementation issue. The same concern does not apply to the compiler. Note that if you run the example program in this issue with there is no UB report, and that is a deliberate aspect of Tree Borrows. But that is just (the general issue is described in ); the same property that makes this well-defined in Tree Borrows also removes some optimizations that people instinctively believe are valid.
Change:
|       +++++++++++++++++ help: consider relaxing the implicit `Sized` restriction | <del> LL | pub trait Foo<RHS=Self: ?Sized> { |                       ++++++++ </del> <ins> LL | pub trait Foo<RHS: ?Sized=Self> { |                  ++++++++ </ins> error: aborting due to 3 previous errors

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
} #[test] <ins> #[cfg_attr(target_env = "sgx", ignore)] // FIXME: https://github.com/fortanix/rust-sgx/issues/31 fn connect_timeout_error() { let socket_addr = next_test_ip4(); let result = TcpStream::connect_timeout(&socket_addr, Duration::MAX); assert!(!matches!(result, Err(e) if e.kind() == ErrorKind::TimedOut)); let _listener = TcpListener::bind(&socket_addr).unwrap(); assert!(TcpStream::connect_timeout(&socket_addr, Duration::MAX).is_ok()); } #[test] </ins> fn listen_localhost() { let socket_addr = next_test_ip4(); let listener = t!(TcpListener::bind(&socket_addr));

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:
<ins> // check-pass #![feature(generic_const_exprs)] #![feature(inline_const)] #![allow(incomplete_features)] pub struct ConstDefaultUnstable<const N: usize = { const { 3 } }>; pub fn main() {} </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
Regression in nightly-2022-03-25 <details<summaryCommits in range</summary</details<details<summaryBisection method</summaryI used: With : On x86_64-apple-darwin </details
So this is not the same root cause as ..? Fascinating :smile:
Triage: Fixed on the latest nightly, labels: +E-needs-test
Change:
impl<'tcx> LateLintPass<'tcx> for PathStatements { fn check_stmt(&mut self, cx: &LateContext<'_>, s: &hir::Stmt<'_>) { <del> if let hir::StmtKind::Semi(ref expr) = s.kind { </del> <ins> if let hir::StmtKind::Semi(expr) = s.kind { </ins> if let hir::ExprKind::Path(_) = expr.kind { cx.struct_span_lint(PATH_STATEMENTS, s.span, |lint| { <del> lint.build("path statement with no effect").emit() </del> <ins> let ty = cx.typeck_results().expr_ty(expr); if ty.needs_drop(cx.tcx, cx.param_env) { let mut lint = lint.build("path statement drops value"); if let Ok(snippet) = cx.sess().source_map().span_to_snippet(expr.span) { lint.span_suggestion( s.span, "use `drop` to clarify the intent", format!("drop({});", snippet), Applicability::MachineApplicable, ); } else { lint.span_help(s.span, "use `drop` to clarify the intent"); } lint.emit() } else { lint.build("path statement with no effect").emit() } </ins> }); } }

Discussion:
() Removing the "no effect" line definitely has effect. The warning may instead suggest to explicitly use if that is what is needed.
Huh, I ran into this a couple weeks ago and typed up an issue, then decided at the last second to back out of it for some reason. Maybe I just figured that writing is more idiomatic anyways. This lint is old, by the way. (in Rust years, anyways)
requires adding before closure (somewhat suprisingly unlike ) Writing instead of may be more idiomatic if one wants to emphasize that running is significant.
Bumping this, as it's relevant to . (See also , ) When the path statement invokes a move, this lint is plain wrong; as the value has been moved, the old binding is no longer usable. When this move invokes drop glue, this lint is even more wrong, because the drop glue is an observable effect, and removing the statement would change the semantics of the program. "Path statement with no effect is further potentially damaging, as it may lead the user to write to silence the warning, which again changes the semantics of the program, because binding to the wildcard pattern does actually not perform a move from the place. I believe the correct behavior for this lint would be to suggest removing path statements that have no associated drop glue, but to suggest for types that do have drop glue, signaling clarity of intent.
Change:
evaluation_cache: Default::default(), reported_trait_errors: Default::default(), reported_closure_mismatch: Default::default(), <del> tainted_by_errors_flag: Cell::new(false), </del> <ins> tainted_by_errors: Cell::new(None), </ins> err_count_on_creation: tcx.sess.err_count(), in_snapshot: Cell::new(false), skip_leak_check: Cell::new(false),

Discussion:
should be to guarantee that we emit an error when that flag is set. This is already done for of other types in rustc. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
renamed to to keep consistent.
Change:
use types::os::arch::posix88::{uid_t}; pub type nlink_t = u16; <del> pub type blksize_t = i64; </del> <ins> pub type blksize_t = u32; </ins> pub type blkcnt_t = i64; pub type fflags_t = u32; #[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:
extern "C" {} #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] <del> #[link(name = "unwind", kind = "static-nobundle")] </del> <ins> #[link(name = "unwind", kind = "static")] </ins> extern "C" {}

Discussion:
Hello, I'm trying to build a pure-LLVM Rust (no linking to at all). Building rust with set as in returns failure since Clang (the C compiler) doesn't allow . Here's my : Here are the relevant bits of the log: Thanks. A complete log is available here:
I think I may have found the culprit. I'm not well-versed in building rustc (I particularly don't know why rust can build its own LLVM instance, but I assume this is to accommodate systems where LLVM doesn't even exist?), but isn't the choice between and is pretty much irrelevant per libc? And by the way, using gcc as , while it does accept the command, it warns (instead of erroring out like clang-9) because isn't supported in the C compiler.
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(rustc_attrs)] #![allow(warnings)] trait A<T> {} struct B<T> where B<T>: A<B<T>> { t: T } #[rustc_error] fn main() { //~ ERROR compilation successful } </ins>

Discussion:
I was trying to compile the following code: And got the following compiler error: Version info:
Still ICEs.
Minimal:
Triage: tracked by glacier
No longer ICEs today. E-needstest. I'm somewhat concerned though because this is the second glacier-tracked ICE that I've seen "fixed."
This was only broken because of the old code.
Change:
) { match &statement.kind { StatementKind::Assign(into, _) => { <del> // Remove any locals that we found were initialized from the // `never_initialized_mut_locals` set. At the end, the only remaining locals will // be those that were never initialized - we will consider those as being used as // they will either have been removed by unreachable code optimizations; or linted // as unused variables. </del> if let Some(local) = into.base_local() { debug!( "visit_statement: statement={:?} local={:?}  never_initialized_mut_locals={:?}", statement, local, self.never_initialized_mut_locals ); <del> let _ = self.never_initialized_mut_locals.remove(&local); </del> } <ins> self.remove_never_initialized_mut_locals(into); </ins> }, _ => {}, }

Discussion:
(sorry if this is an duplicate or the wrong repo :innocent: ) () Current behavior: no warning Expected behavior: The variable clearly doesn't need to be mutable, still, nothing is detected and no warning is emitted. Rust 1.35.0 (Using the , also in ())
The warning appears again if you switch to 2015 edition. Huh. Nice catch!
I found that Stable 2015 edition produces the warning and everything else doesn't.
cc (likely caused by NLL migrate mode, which was enabled in for the 2015 edition)
Yes, looks like another nll bug. If someone wants to have a go at this, the issue is that we are treating DropAndReplace differently to Assign for the purposes of this lint.
I can try doing it I just don't know here to begin.
I don't know this code too well, but take a look at . The first thing I'd try is adding a case for to the match in that mirrors what's done for .
Makes sense thank you. I was looking at librustc_lint and couldn't find anything.
Change:
variant_index: VariantIdx, ) -> InterpResult<'tcx, Option<(ScalarInt, usize)>> { match self.layout_of(ty)?.variants { <del> abi::Variants::Single { .. } => Ok(None), </del> <ins> abi::Variants::Single { .. } => { // The tag of a `Single` enum is like the tag of the niched // variant: there's no tag as the discriminant is encoded // entirely implicitly. If `write_discriminant` ever hits this // case, we do a "validation read" to ensure the the right // discriminant is encoded implicitly, so any attempt to write // the wrong discriminant for a `Single` enum will reliably // result in UB. Ok(None) } </ins> abi::Variants::Multiple { tag_encoding: TagEncoding::Direct,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
<ins> #![cfg_attr(feat, feature(coverage_attribute))] //@ revisions: feat nofeat //@ compile-flags: -Cinstrument-coverage //@ needs-profiler-support // Malformed `#[coverage(..)]` attributes should not cause an ICE when built // with `-Cinstrument-coverage`. // Regression test for <https://github.com/rust-lang/rust/issues/127880>. #[coverage] //~^ ERROR malformed `coverage` attribute input //[nofeat]~| the `#[coverage]` attribute is an experimental feature fn main() {} // FIXME(#130766): When the `#[coverage(..)]` attribute is stabilized, // get rid of the revisions and just make this a normal test. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected value of coverage attribute', 'error: internal compiler error: unexpected value of coverage attribute' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [coverageattron] checking for on [mirbuilt] building MIR for -- label +F-coverageattribute
Regression in
Change:
// // 1. Check if they have been resolved, and if so proceed with //    THAT type. <del> // 2. If not, check whether this is the type that we //    started with (ty0). In that case, we've made no //    progress at all, so return false. Otherwise, //    we've at least simplified things (i.e., we went //    from `Vec<$0>: WF` to `$0: WF`, so we can </del> <ins> // 2. If not, we've at least simplified things (e.g., we went //    from `Vec<$0>: WF` to `$0: WF`), so we can </ins> //    register a pending obligation and keep //    moving. (Goal is that an "inductive hypothesis" //    is satisfied to ensure termination.) <ins> // See also the comment on `fn obligations`, describing "livelock" // prevention, which happens before this can be reached. </ins> ty::Infer(_) => { let ty = self.infcx.shallow_resolve(ty); <del> if let ty::Infer(_) = ty.kind { // not yet resolved... if ty == ty0 { // ...this is the type we started from! no progress. return false; } </del> <ins> if let ty::Infer(ty::TyVar(_)) = ty.kind { // Not yet resolved, but we've made progress. </ins> let cause = self.cause(traits::MiscObligation); <del> self.out.push( // ...not the type we started from, so we made progress. traits::Obligation::new( cause, self.param_env, ty::Predicate::WellFormed(ty), ), ); </del> <ins> self.out.push(traits::Obligation::new( cause, param_env, ty::Predicate::WellFormed(ty), )); </ins> } else { <del> // Yes, resolved, proceed with the // result. Should never return false because // `ty` is not a Infer. assert!(self.compute(ty)); </del> <ins> // Yes, resolved, proceed with the result. // FIXME(eddyb) add the type to `walker` instead of recursing. self.compute(ty); </ins> } } } } <del> // if we made it through that loop above, we made progress! true </del> } fn nominal_obligations(

Discussion:
returns if it can't make progress on an inference variable, and the original obligation should be retried later. However, doesn't check that return type and may (incorrectly) return no obligations. On I suggested this: I'm pretty sure now that it would've prevented this bug. <hr/Looking at the users, only uses this function, and only for the user-specified bounds, so it's possible inference variables are impossible to find (unless normalization introduces them, I guess?). It might be fine to just create obligation for the instead of bailing out (see below, this is the same as moving out of ) It's true that can't be found as the first type in the recursive call, but is a , and it uses . (EDIT: Read the code more carefully and the check is , so while it's not an early like I would prefer, it does seem to only trigger on the root type) However, a few other things call and it would be fine for them to create an obligation rather than erroring out, so maybe itself should do that check? cc
changes the return type of to a and discards it using . Might cause us to be slightly more cautious in the future.
I'm working on a fix that makes itself never bail out, so the check is done in , hopefully that will also work nicely for consts. EDIT: opened .
Change:
} fn check_stmt(&mut self, cx: &EarlyContext<'_>, s: &ast::Stmt) { <del> if let ast::StmtKind::Local(ref local) = s.kind { self.check_unused_parens_pat(cx, &local.pat, false, false); </del> <ins> use ast::StmtKind::*; </ins> <del> if let Some(ref value) = local.init { self.check_unused_parens_expr(cx, &value, "assigned value", false, None, None); </del> <ins> match s.kind { Local(ref local) => { self.check_unused_parens_pat(cx, &local.pat, false, false); if let Some(ref value) = local.init { self.check_unused_parens_expr(cx, &value, "assigned value", false, None, None); } </ins> } <ins> Expr(ref expr) => { self.check_unused_parens_expr(cx, &expr, "block return value", false, None, None); } _ => {} </ins> } }

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
else: sys.exit(err) <ins> def run_powershell(script, *args, **kwargs): """Run a powershell script""" run(["PowerShell.exe", "/nologo", "-Command"] + script, *args, **kwargs) </ins> def require(cmd, exit=True, exception=False): '''Run a command, returning its output.

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. 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. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.