jiebi/CodeConvo huggingface dataset:
Change:
|                                                                 | |                                                                 function or associated item not found in `Backtrace` |                                                                 help: there is an associated function with a similar name: `force_capture` <ins> | note: if you're trying to build a new `Backtrace` consider using one of the following associated functions: Backtrace::capture Backtrace::force_capture Backtrace::disabled Backtrace::create --> $SRC_DIR/std/src/backtrace.rs:LL:COL </ins> error: aborting due to previous error

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
<ins> // compile-pass fn main() { let s = &[0x00; 4][..]; //Slice of any value const MAGIC_TEST: &[u32] = &[4, 5, 6, 7]; //Const slice to pattern match with match s { MAGIC_TEST => (), [0x00, 0x00, 0x00, 0x00] => (), [4, 5, 6, 7] => (), // this should warn _ => (), } match s { [0x00, 0x00, 0x00, 0x00] => (), MAGIC_TEST => (), [4, 5, 6, 7] => (), // this should warn _ => (), } match s { [0x00, 0x00, 0x00, 0x00] => (), [4, 5, 6, 7] => (), MAGIC_TEST => (), // this should warn _ => (), } } </ins>

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
// be replaced with calling `insert` to re-set the bit). if kind == LocalKind::Temp { if !self.temp_promotion_state[index].is_promotable() { <del> assert!(self.cx.per_local[IsNotPromotable].contains(index)); </del> <ins> assert!(self.cx.per_local[IsNotConst].contains(index)); </ins> } } }

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
<ins> // Checks that catch_unwind can be used if unwinding is already in progress. // Used to fail when standard library had been compiled with debug assertions, // due to incorrect assumption that a current thread is not panicking when // entering the catch_unwind. // // run-pass // ignore-wasm       no panic support // ignore-emscripten no panic support use std::panic::catch_unwind; #[derive(Default)] struct Guard; impl Drop for Guard { fn drop(&mut self) { let _ = catch_unwind(|| {}); } } fn main() { let _ = catch_unwind(|| { let _guard = Guard::default(); panic!(); }); } </ins>

Discussion:
In particular panics because of failing assert in For example:
Cc I think that assert doesn't make much sense if I'm interpreting correctly, though I'm surprised it hasn't been hit before...
The current implementation seems to incorrectly assume that unwinding is not in progress when entering . Not caught before, since std is usually used without debug assertions (it definitely happens in actually existing code, what is unusual is that I am using and hence hitting the assertion). There is a similar although a separate question if following should abort or not:
Yes, the second code snippet should definitely abort - we abort on the second live panic, independent of whether it's going to be caught.
Change:
<ins> struct S<A, B>(Option<(A, B)>); impl<A, B> S<A, B> { fn infer(&self, a: A, b: B) {} //~^ NOTE associated function defined here //~| NOTE //~| NOTE } fn main() { let s = S(None); s.infer(0i32); //~^ ERROR this method takes 2 arguments but 1 argument was supplied //~| NOTE an argument is missing //~| HELP provide the argument let t: S<u32, _> = s; //~^ ERROR mismatched types //~| NOTE expected `S<u32, _>`, found `S<i32, _>` //~| NOTE expected due to this //~| NOTE expected struct `S<u32, _>` } </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. --Ran into an ICE while refactoring. Only happens on nightly. Don't know what else I should write here. <!-- 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 --
I cannot reproduce this using on . I ran it on Could you try bisecting this yourself locally (I am not able to right now)
I hit this same bug and got a patch, can post a PR soon if useful!
Sounds great! assign
Change:
/// `GetLastError` on Windows) and will return a corresponding instance of /// [`Error`] for the error code. /// <ins> /// This should be called immediately after a call to a platform function, /// otherwise the state of the error value is indeterminate. In particular, /// other standard library functions may call platform functions that may /// (or may not) reset the error value even if they succeed. /// </ins> /// # Examples /// /// ``` /// use std::io::Error; /// <del> /// println!("last OS error: {:?}", Error::last_os_error()); </del> <ins> /// let os_error = Error::last_os_error(); /// println!("last OS error: {:?}", os_error); </ins> /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[must_use]

Discussion:
This happens on Windows 7, cannot test on newer Windows. Basically, something wrong happens with file handles when using the macro, not sure what exactly. Minimal repro: Actual output: Expected output: Sorry for German localization in the error messages. I noticed this because of some obscure behaviour in the windows API (a function returned != 0, but LastError wasn't set accordingly). cc cc
Additional info: I am using stable rust 1.28
Works for me on Windows 10: 1.27.2 1.28 beta nightly Can't test Windows 7 :( sorry
Does it occur more than once? (e.g. can you reproduce it?)
Yes, this happens every time I execute the program
("Das Handle ist ungültig" means "The handle is invalid" in English)
Seems like it could be this call:
Windows system functions generally guarantee that they will set the last error when they fail, but offer no guarantees as to the state of the last error when they succeed (some may clear the error, some may leave it alone, some may change it). The only action that Rust could take here is for any libstd function that calls system functions to clear the last error when it returns success.
I'm using on windows 7 (which is just the mingw terminal if I'm not mistaken). Probably that resolves to in the call you mentioned. Maybe we should in that branch? I understand this is not really a bug (if the function errors, we have a pipe, otherwise a terminal), but perhaps we can reduce the confusion if we reset the OS error in the former case.
Personally I'd rather that Rust offer no guarantees about the result of when called after any libstd function that calls some system function. It should only be used directly after calling a system function yourself and only when that function is documented to have set the last error. There is a case to be made here about documenting this though.
Triage: I agree, though we should get signoff before re-categorizing this bug.
Same problem. As I see line break affects. Normal: Normal: Bug: Bug: Windows 10 51.0-nightly 49.0-stable
Change:
&format!("`#[{}({})]` on by default", level.as_str(), name), ); } <del> LintSource::CommandLine(lint_flag_val) => { let flag = match level { </del> <ins> LintSource::CommandLine(lint_flag_val, orig_level) => { let flag = match orig_level { </ins> Level::Warn => "-W", Level::Deny => "-D", Level::Forbid => "-F", <del> Level::Allow => panic!(), </del> <ins> Level::Allow => "-A", </ins> }; let hyphen_case_lint_name = name.replace("_", "-"); if lint_flag_val.as_str() == name {

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. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
<ins> error: expected `|`, found `}` --> $DIR/issue-43196.rs:13:1 | LL |     | |      - expected `|` here LL | } | ^ unexpected token error: expected item, found `|` --> $DIR/issue-43196.rs:15:1 | LL | | | ^ expected item error: aborting due to 2 previous errors </ins>

Discussion:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.
Change:
/// to be). pub(super) fn generate_coverage_spans( mir_body: &'a mir::Body<'tcx>, <del> fn_sig_span: Span, </del> <ins> fn_sig_span: Span, // Ensured to be same SourceFile and SyntaxContext as `body_span` </ins> body_span: Span, basic_coverage_blocks: &'a CoverageGraph, ) -> Vec<CoverageSpan> { let mut coverage_spans = CoverageSpans { mir_body, <del> fn_sig_span: fn_sig_source_span(fn_sig_span, body_span), </del> <ins> fn_sig_span, </ins> body_span, basic_coverage_blocks, sorted_spans_iter: None,

Discussion:
See below. Last nightly version that was known to work was 2021-04-19. Note that it says below but this is the version that installs as ! Similarly is the last known to work version but installed via as .
points at the following: searched nightlies: from nightly-2021-04-18 to nightly-2021-04-22 regressed nightly: nightly-2021-04-21 searched commits: from to regressed commit:
Because it was a small change, I have a guess about what I may need to check, but it would help to have an MCVE. I can't tell what code you're compiling that caused this. Can you provide a small example I can build locally? Thanks! cc:
By the way, where is the source for ? It looks like it is gone from github. I tried building , on the off chance that it might cause the same ICE with , but it built without issues.
We're having the same issue, if this helps: I'll see if I can get a minimal example
I don't have a minimal example, had no time to dig through the code yet to understand the problem. But you can easily reproduce it via
Ah! Thanks for providing the link to the source. I wasn't sure how to get it without access to the repo. Yes I can reproduce this. Looking into it now. Thanks!
Change:
TerminatorKind::Goto { .. } | TerminatorKind::Resume | TerminatorKind::Abort | <del> TerminatorKind::Return | </del> TerminatorKind::GeneratorDrop | TerminatorKind::Unreachable | TerminatorKind::FalseEdges { .. } | TerminatorKind::FalseUnwind { .. } => { } <ins> TerminatorKind::Return => { // `return` logically moves from the return place `_0`. Note that the place // cannot be changed by any visitor, though. let $($mutability)? local = RETURN_PLACE; self.visit_local( & $($mutability)? local, PlaceContext::NonMutatingUse(NonMutatingUseContext::Move), source_location, ); assert_eq!( local, RETURN_PLACE, "`MutVisitor` tried to mutate return place of `return` terminator" ); } </ins> TerminatorKind::SwitchInt { discr, switch_ty,

Discussion:
The terminator conceptually moves out of the return place , but this is not currently reflected by the visitor infrastructure. This can lead to incorrect dataflow solutions for . For example, reports that is dead before a , which is wrong (it must always be live there). These don't currently cause any harm, since use of is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate to arbitrary places in the function and needs to have correct information to do so soundly. The simple fix of calling from within has the problem that the receives a , but the local reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this? cc
I think any alternative will be more complex than that simple assertion. Conceptually the should contain a which is always , but then we'd need to have assertions keeping that in place, so you don't gain anything. I don't think we can generalize returning to allow using different places than , which is the only way we'd get around having to assert something somewhere.
Change:
<ins> // The WF requirements of the *unnormalized* form of type annotations // can guide inference. // check-pass pub trait EqualTo { type Ty; } impl<X> EqualTo for X { type Ty = X; } trait MyTrait<U: EqualTo<Ty = Self>> { type Out; } impl<T, U: EqualTo<Ty = T>> MyTrait<U> for T { type Out = (); } fn main() { let _: <_ as MyTrait<u8>>::Out; // We shoud be able to infer a value for the inference variable above. // The WF of the unnormalized projection requires `u8: EqualTo<Ty = _>`, // which is sufficient to guide inference. } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-10-01 to nightly-2023-11-04 regressed nightly: nightly-2023-10-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
That’s from cc was this done on purpose maybe to find cases like this?
Why the heck do we even resolve in the first place?!

edit: This behavior changed in: commit[0] 2023-01-08: Auto merge of - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum commit[1] 2023-01-08: Auto merge of - geeklint:loosenweakdebugbound, r=dtolnay commit[2] 2023-01-09: Auto merge of - compiler-errors:rollup-emcj0o3, r=compiler-errors commit[3] 2023-01-09: Auto merge of - compiler-errors:better-spans-on-bad-tys, r=lcnr commit[4] 2023-01-09: Auto merge of - saethlin:propagate-operands, r=oli-obk commit[5] 2023-01-09: Auto merge of - aliemjay:astconv-normalize, r=lcnr commit[6] 2023-01-09: Auto merge of - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead
Ah, it's because of the where-clause on . This would be fixed if checked wf in before normalization and not after, since that sufficiently constrains the self type of the projection so it can proceed in the query. cc:
This is ultimately fixed by , but until then the PR should be temporarily reverted (with a beta-1.75 backport). I'll do the revert when the crater run for beta-1.75 finishes in order to discover other regressions. The reverted commit is small and safe enough to backport at any time, I believe, so I'm fine with this. Please let me know if you think this should be done earlier. claim
Error and stacktrace look similar to (now solved). Or maybe this is just something different ?
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
[lib] path = "lib.rs" <ins> [features] Win32 = ["Win32_System"] Win32_System = ["Win32_System_Diagnostics"] Win32_System_Diagnostics = ["Win32_System_Diagnostics_Debug"] Win32_System_Diagnostics_Debug = [] default = ["Win32"] </ins> [dependencies] implementors = { path = "./implementors" } http = { path = "./http" }

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
/// Installs everything. pub fn install(build: &Build, stage: u32, host: &str) { <del> let prefix = build.config.prefix.as_ref().clone().map(|x| Path::new(x)) .unwrap_or(Path::new("/usr/local")); let docdir = build.config.docdir.as_ref().clone().map(|x| Cow::Borrowed(Path::new(x))) .unwrap_or(Cow::Owned(prefix.join("share/doc/rust"))); let libdir = build.config.libdir.as_ref().clone().map(|x| Cow::Borrowed(Path::new(x))) .unwrap_or(Cow::Owned(prefix.join("lib"))); let mandir = build.config.mandir.as_ref().clone().map(|x| Cow::Borrowed(Path::new(x))) .unwrap_or(Cow::Owned(prefix.join("share/man"))); </del> <ins> let prefix_default = PathBuf::from("/usr/local"); let docdir_default = PathBuf::from("share/doc/rust"); let mandir_default = PathBuf::from("share/man"); let libdir_default = PathBuf::from("lib"); let prefix = build.config.prefix.as_ref().unwrap_or(&prefix_default); let docdir = build.config.docdir.as_ref().unwrap_or(&docdir_default); let libdir = build.config.libdir.as_ref().unwrap_or(&libdir_default); let mandir = build.config.mandir.as_ref().unwrap_or(&mandir_default); let docdir = prefix.join(docdir); let libdir = prefix.join(libdir); let mandir = prefix.join(mandir); let destdir = env::var_os("DESTDIR").map(PathBuf::from); let prefix = add_destdir(&prefix, &destdir); let docdir = add_destdir(&docdir, &destdir); let libdir = add_destdir(&libdir, &destdir); let mandir = add_destdir(&mandir, &destdir); </ins> let empty_dir = build.out.join("tmp/empty_dir"); t!(fs::create_dir_all(&empty_dir)); if build.config.docs { <del> install_sh(&build, "docs", "rust-docs", stage, host, prefix, </del> <ins> install_sh(&build, "docs", "rust-docs", stage, host, &prefix, </ins> &docdir, &libdir, &mandir, &empty_dir); } <del> install_sh(&build, "std", "rust-std", stage, host, prefix, </del> <ins> install_sh(&build, "std", "rust-std", stage, host, &prefix, </ins> &docdir, &libdir, &mandir, &empty_dir); <del> install_sh(&build, "rustc", "rustc", stage, host, prefix, </del> <ins> install_sh(&build, "rustc", "rustc", stage, host, &prefix, </ins> &docdir, &libdir, &mandir, &empty_dir); t!(fs::remove_dir_all(&empty_dir)); }

Discussion:
No destdir is passed to in
That causes fail in Gentoo build
As far as I understand, we need to to pass to function and add value of to prefix here
Change:
<ins> // aux-build:proc-macro-panic.rs // edition:2018 // ignore-stage1 // only-linux // // FIXME: This should be a normal (stage1, all platforms) test in // src/test/ui/proc-macro once issue #59998 is fixed. // Regression test for issue #76270 // Tests that we don't print an ICE message when a panic // occurs in libproc-macro (when `-Z proc-macro-backtrace` is not specified) extern crate proc_macro_panic; proc_macro_panic::panic_in_libproc_macro!(); //~ ERROR proc macro panicked fn main() {} </ins>

Discussion:
Between nightly-2020-08-29 and nightly-2020-09-02, the following began printing an ICE message (despite compiling successfully). The relevant compiler commit range is appears extremely relevant so mentioning From the PR description it sounds like the PR was intended to have no effect unless the new -Z flag is passed. Is it possible it could be causing this? Before: After:
It looks like I misunderstood how works. I'll PR a fix tomorrow.
Assigning as and removing .
PR is up at