jiebi/CodeConvo huggingface dataset:
Change:
[[package]] name = "linux-raw-sys" <del> version = "0.4.7" </del> <ins> version = "0.4.10" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "1a9bad9f94746442c783ca431b22403b519cd7fbeed0533fdd6328b2f2212128" </del> <ins> checksum = "da2479e8c062e40bf0066ffa0bc823de0a9368974af99c9f6df941d2c231e03f" </ins> [[package]] name = "litemap"

Discussion:
IIRC we agreed upon the notion of a "slot", which is a simple way to create a mutable interior value. This lets us abstract over the mutable and immutable vectors without the subtyping relation that "mutable?" introduces, which is painful (and which we never got right in the presence of generics). So you could construct a slot using, say, , and that creates a mutable pseudo-box that is interior. Slots have no representation at the IR level; they're purely a way to help us enforce immutability restrictions. would become , would become , etc. This may be appropriate for the first milestone, depending on how serious we consider the type soundness hole with generics to be for 0.1.
So taking the value of a slot in a non-lvalue context would be an error?
Actually thinking through this more, slots have several weird issues relating to autoderef and generic functions. Talked this over with Dave and I think it makes sense to keep , but to fix the issue with covariance/invariance and rename it to something a little less gross ( maybe?)
Dupe of issue .
Change:
// rlibs/dylibs. let sess = self.sess; let dylibname = self.dylibname(); <del> let mut locs = locs.iter().map(|l| Path::new(l.as_slice())).filter(|loc| { if !loc.exists() { sess.err(format!("extern location does not exist: {}", loc.display()).as_slice()); return false; } let file = loc.filename_str().unwrap(); if file.starts_with("lib") && file.ends_with(".rlib") { return true } else { match dylibname { Some((prefix, suffix)) => { if file.starts_with(prefix) && file.ends_with(suffix) { return true </del> <ins> let mut rlibs = HashSet::new(); let mut dylibs = HashSet::new(); { let mut locs = locs.iter().map(|l| Path::new(l.as_slice())).filter(|loc| { if !loc.exists() { sess.err(format!("extern location for {} does not exist: {}", self.crate_name, loc.display()).as_slice()); return false; } let file = match loc.filename_str() { Some(file) => file, None => { sess.err(format!("extern location for {} is not a file: {}", self.crate_name, loc.display()).as_slice()); return false; } }; if file.starts_with("lib") && file.ends_with(".rlib") { return true } else { match dylibname { Some((prefix, suffix)) => { if file.starts_with(prefix) && file.ends_with(suffix) { return true } </ins> } <ins> None => {} </ins> } <del> None => {} </del> } <del> } sess.err(format!("extern location is of an unknown type: {}", loc.display()).as_slice()); false }); </del> <ins> sess.err(format!("extern location for {} is of an unknown type: {}", self.crate_name, loc.display()).as_slice()); false }); </ins> <del> // Now that we have an iterator of good candidates, make sure there's at // most one rlib and at most one dylib. let mut rlibs = HashSet::new(); let mut dylibs = HashSet::new(); for loc in locs { if loc.filename_str().unwrap().ends_with(".rlib") { rlibs.insert(fs::realpath(&loc).unwrap()); } else { dylibs.insert(fs::realpath(&loc).unwrap()); </del> <ins> // Now that we have an iterator of good candidates, make sure there's at // most one rlib and at most one dylib. for loc in locs { if loc.filename_str().unwrap().ends_with(".rlib") { rlibs.insert(fs::realpath(&loc).unwrap()); } else { dylibs.insert(fs::realpath(&loc).unwrap()); } </ins> } <del> } </del> <ins> }; </ins> // Extract the rlib/dylib pair. let mut metadata = None;

Discussion:
This looks like , but I'm running . The error message was With this stacktrace: I'm on an i686 Ubuntu 14.04.1 LTS Vagrant VM (the ) on OS X 10.9.5
Actually, I just took another look at the command line, and it had . That's probably where the value came from, but I don't know if it's the expected error message.
Yep, this should definitely have a better error message.
Do you happen to have a code example that triggers this?
I don't have code, but specifying a value for seemed to fix the problem, so I think that's it.
fixing it now.
Change:
BuiltinLintDiagnostics::UnexpectedCfgName((name, name_span), value) => { let possibilities: Vec<Symbol> = sess.parse_sess.check_config.expecteds.keys().copied().collect(); <ins> let mut names_possibilities: Vec<_> = if value.is_none() { // We later sort and display all the possibilities, so the order here does not matter. #[allow(rustc::potential_query_instability)] sess.parse_sess .check_config .expecteds .iter() .filter_map(|(k, v)| match v { ExpectedValues::Some(v) if v.contains(&Some(name)) => Some(k), _ => None, }) .collect() } else { Vec::new() }; </ins> let is_from_cargo = std::env::var_os("CARGO").is_some(); let mut is_feature_cfg = name == sym::feature;

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
<ins> error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: this file contains an unclosed delimiter --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11 | LL | fn a(){{{ |       --- ^ |       ||| |       ||unclosed delimiter |       |unclosed delimiter |       unclosed delimiter error: aborting due to 3 previous errors </ins>

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
reduced:
reduced further claim I think try to get a span from to but we work around and assume that since we don't have a , it must be somewhere near EOF. When we then try to point at it via diagnostics, we get the error that we don't have anything to actually point to.
Change:
<ins> error: expected at least one digit in exponent --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ error: unexpected token: `5.2E+` --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `5.2E+` --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ expected one of `.`, `;`, `?`, `}`, or an operator error: aborting due to 3 previous errors </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. Affected versions: probably all versions since that panic was introduced, I tried nightly 2021-11-07 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsA quick inspection of the code shows that the similar case is handled the same as : So if I had to guess I would say that the match is missing this one case, so should be handled the same as : But no idea what does that code even do, it has a FIXME by so maybe he knows better. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
pub type CommandResult<T> = Result<T, CommandError>; pub fn err(s: &str) -> CliError { <ins> #[derive(Debug)] </ins> struct E(String); impl Error for E {

Discussion:
currently requires , while requires . I'm unsure of what each should require, but I think they should agree so that it is possible to have code which returns (which is useful to allow try! across functions returning different types of error codes), and be able to the results.
There was a lengthy discussion about this towards the bottom of the RFC:
/cc , I vaguely remember this might change? If not, then this should be in the RFCs repo.
Nominating for 1.0-beta P-backcompat-libs. (The trait isn't yet, but it probably will be for 1.0).
0 beta, P-backcompat-libs, I-needs-decision.
Change:
'middle-of-struct 'before-start-of-struct 'after-end-of-struct #'mark-defun)) <ins> (ert-deftest indent-line-blank-line-motion () (rust-test-motion rust-test-indent-motion-string 'blank-line-indent-start 'blank-line-indent-target #'indent-for-tab-command)) (ert-deftest indent-line-closing-brace-motion () (rust-test-motion rust-test-indent-motion-string 'closing-brace-indent-start 'closing-brace-indent-target #'indent-for-tab-command)) (ert-deftest indent-line-middle-push-motion () (rust-test-motion rust-test-indent-motion-string 'middle-push-indent-start 'middle-push-indent-target #'indent-for-tab-command)) (ert-deftest indent-line-after-whitespace-motion () (rust-test-motion rust-test-indent-motion-string 'after-whitespace-indent-start 'after-whitespace-indent-target #'indent-for-tab-command)) (ert-deftest indent-line-middle-pull-motion () (rust-test-motion rust-test-indent-motion-string 'middle-pull-indent-start 'middle-pull-indent-target #'indent-for-tab-command)) </ins>

Discussion:
There are several common cases where the emacs mode gets the indentation incorrect. I'll list the examples as I believe they should be formatted. indent after open paren with no argument: with arguments: field names:
Oh, and the motivating example for filing the bug: comments don't work quite right. and also you should be able to hit M-q and have it reflow correctly.
I've found trailing line comments breaks the indentation of the next line: (Not sure if this is worth a separate bug.)
Another example is a pattern relative to an indented match: Also, I believe patterns in general are indented incorrectly, though admittedly I'm not sure what the standard is. My preference is to keep all patterns at the same level of indentation, as shown here:
If we're going to fix , we should try to also take the time to fix the other doc comment variations, namely , if possible.
part of
Change:
$$(CFG_GCCISH_LINK_FLAGS_$(1))  $$(CFG_GCCISH_DEF_FLAG_$(1))$$(3) $$(2)  $$(call CFG_INSTALL_NAME_$(1),$$(4)) <del> CFG_COMPILE_CXX_$(1) = '$$(CXX_$(1))'  </del> <ins> CFG_COMPILE_CXX_$(1) = '$$(call FIND_COMPILER,$$(CXX_$(1)))'  </ins> $$(CXXFLAGS)  $$(CFG_GCCISH_CFLAGS)  $$(CFG_GCCISH_CXXFLAGS) 

Discussion:
I'm building Rust with , it fails at the miniz step:
This is due to , specifically . The problem is that --enable-ccache exports and it's ambiguous whether that's a file name with a space in it or two arguments.
Change:
); if node.is_some() { // Only provide the help if its a local trait, otherwise it's not <del> violation.solution(err); </del> <ins> violation.solution().add_to(err); </ins> } err },

Discussion:
made it so that we report all object safety violations at the same time. However, it also results in a redundant note: We should not add the same note multiple times.
Can we add a debug assertion for duplicate identical help messages? (sorta like we do for "Span must not be empty and have no suggestion" or "Suggestion may not have overlapping parts" ?
I guess we could, but I think there are multiple diagnostics that currently do this, so we'll have to fix them first.
Did not find tooo much... inside :
Change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-62546.rs:3:53 | LL | pub t(# |      - un-closed delimiter LL | LL | |                                                     ^ error: missing `fn` or `struct` for function or struct definition --> $DIR/issue-62546.rs:1:4 | LL | pub t(# | ---^- help: if you meant to call a macro, try: `t!` error: aborting due to 2 previous errors </ins>

Discussion:
I see the following error on the and channels, but not on : Found with the help of .
triage: P-high, because errors being swallowed, even in the presence of other errors, scares me a bit.
Perhaps might be a good candidate to investigate?
The error that is not being emitted is ~Looking.~ Found, incoming PR shortly.
Change:
<ins> #![feature(core_intrinsics)] use std::intrinsics::type_name; struct Bar<M>(M); impl<M> Bar<M> { fn foo(&self) -> &'static str { fn f() {} fn type_name_of<T>(_: T) -> &'static str { unsafe { type_name::<T>() } } type_name_of(f) } } fn main() { assert_eq!(Bar(()).foo(), "issue_61894::Bar<_>::foo::f"); } </ins>

Discussion:
I believe this happened after
triage: P-high because it blocks presumed stabilization of (). Removing nomination tag.
you can have parameterization in scope that's not part of monomorphization (like the above). For name mangling (with the new scheme) we produce something that demangles to in that case. We could use in this case too.
I'm working on a fix that uses .
Change:
for arm in arms { // Check the arm for some things unrelated to exhaustiveness. <del> self.check_patterns(&arm.pat); </del> <ins> self.check_patterns(&arm.pat, Refutable); </ins> if let Some(hir::Guard::IfLet(ref pat, _)) = arm.guard { <del> self.check_patterns(pat); </del> <ins> self.check_patterns(pat, Refutable); </ins> let tpat = self.lower_pattern(&mut cx, pat, &mut false); check_let_reachability(&mut cx, pat.hir_id, tpat, tpat.span()); }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
.iter() .find(|did| tcx.item_name(**did) == callee_name) { <ins> // using internal substs is ok here, since this is only // used for the `resolve` call below substs = InternalSubsts::identity_for_item(tcx, did); </ins> callee = did; } } <del> _ => { if !tcx.is_const_fn_raw(callee) { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; } </del> <ins> _ if !tcx.is_const_fn_raw(callee) => { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; </ins> } } <ins> } </ins> <del> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; } </del> <ins> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; </ins> } } <ins> _ => {} </ins> } // Resolve a trait method call to its concrete implementation, which may be in a

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. --code from glacier/fixed/-1.rs <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.
Change:
#[track_caller] fn check_all_outcomes<T: Eq + Hash + fmt::Display>(expected: HashSet<T>, generate: impl Fn() -> T) { let mut seen = HashSet::new(); <del> // Let's give it 8x as many tries as we are expecting values. let tries = expected.len() * 8; </del> <ins> // Let's give it sixteen times as many tries as we are expecting values. let tries = expected.len() * 16; </ins> for _ in 0..tries { let val = generate(); assert!(expected.contains(&val), "got an unexpected value: {val}");

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. --I tried this code: Compile with on () I expected to see this happen: Both functions should compile to approximately the same thing, with no bounds check on the since the optimizer should be able to see that the slice is at least of length 2 due to the previous unchecked indexing. Instead, this happened: contains a bounds check (only does not contain a bounds check). rustc stable (1.73.0), nightly (2023-10-17), and 1.58.0 (when was stabilized) all have approximately the same codegen. : (no backtrace) label +C-optimization -C-bug
contains an assume intrinsic, doesn't. Might be worth adding it to the latter and see how that impacts perf, it's not guaranteed that it would actually improve things since we'd be emitting more IR and llvm would have to work harder. Commonly it's the case that if one uses one does so for all accesses on the slice, so this seems like an unusual pattern.
Change:
assert_eq!(predicates.predicates.len(), predicates.spans.len()); let wf_obligations = iter::zip(&predicates.predicates, &predicates.spans).flat_map(|(&p, &sp)| { <del> traits::wf::predicate_obligations(infcx, wfcx.param_env, wfcx.body_id, p, sp) </del> <ins> traits::wf::predicate_obligations( infcx, wfcx.param_env.without_const(), wfcx.body_id, p, sp, ) </ins> }); let obligations: Vec<_> = wf_obligations.chain(default_obligations).collect();

Discussion:
Found in : https://crater- Looking briefly into the code it's doing something pretty weird (e.g., transmutes ), but at the very least this diagnostic seems unfortunate.
searched nightlies: from nightly-2022-04-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThis regressed in cc
Maybe "regressed" is better here, maybe it's a legitimate reason to fail. Haven't looked into it.
I'm going to look into this later, but it seems like a case of wf checks requiring const bounds.
Repro:
Just to be sure I understood: is the regression about code that should compile in the next Rust 1.64 or is that code now invalid code and the regression is just a bad diagnostic? thanks!
The code is valid. It should compile in the next Rust 1.64. Hope that helps.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
compiler.host, target_compiler.host, target); <del> let libdir = build.sysroot_libdir(&target_compiler, target); let out_dir = build.cargo_out(&compiler, Mode::Libstd, target); t!(fs::create_dir_all(&libdir)); add_to_sysroot(&out_dir, &libdir); </del> <ins> let libdir = build.sysroot_libdir(target_compiler, target); add_to_sysroot(&libdir, &libstd_stamp(build, compiler, target)); </ins> if target.contains("musl") && !target.contains("mips") { copy_musl_third_party_objects(build, target, &libdir);

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.
Change:
<ins> error: expected type, found `123` --> $DIR/diagnostics-parenthesized-type-arguments-issue-120892-2.rs:2:45 | LL |   foo::/* definitely not harmful comment */(123, "foo") -> (u32); |      ---------------------------------------^^^ expected type |      | |      while parsing this parenthesized list of type arguments starting here error: aborting due to 1 previous error </ins>

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.