jiebi/CodeConvo huggingface dataset:
Code change:
#[unstable(feature = "context_ext", issue = "123392")] #[rustc_const_unstable(feature = "const_waker", issue = "102012")] pub const fn ext(&mut self) -> &mut dyn Any { <del> match &mut self.ext { </del> <ins> // FIXME: this field makes Context extra-weird about unwind safety // can we justify AssertUnwindSafe if we stabilize this? do we care? match &mut *self.ext { </ins> ExtData::Some(data) => *data, ExtData::None(unit) => unit, }

Related discussion:
text: https://crater-
I'll need to re-check later but this seems to bisect to somehow.
The UI test changes from that PR appear to back this up, as confusing as it is.
I'm not sure what's going on in that crate, if it built successfully by mistake, or how that PR interacts with it, so let's cc the PR author and reviewer for validation.
After , no longer implements and , because the context now contains a which doesn't implement those traits. So this is an issue with the standard library and not the crate being built. Repro: label -T-compiler +T-libs +S-has-mcve
WG-prioritization assigning priority (). Noticing this on which says that was meant to be confined on nightly. Unsure about the fallout of this regression but for now marking as critical for tracking purposes. label -I-prioritize +P-critical
Revert up:
Isn't not unwind safe?
That line was by your PR, so while what you say is technically true, talking about what "already happened" when we are traveling back and forth through time via version control may be more confusing than helpful.
That line was already there. I the line below it though. Original PR:
Apologies, I guess I can't count numbers today? Hm, so, the full error of the regression is this: Note that it's trying to make a pointer implement . And for what it's worth, stable does indeed document is . Thus unfortunately that line you pointed to, as opposed to the one I thought you were referring to, is effectively just documenting that all are , and that will include regardless of whether it is is . And confusingly, , unlike .
I have opened as an alternative.
Code change:
config.out = absolute(&config.out).expect("can't make empty path absolute"); } <ins> if cargo_clippy.is_some() && rustc.is_none() { println!( "WARNING: Using `build.cargo-clippy` without `build.rustc` usually fails due to toolchain conflict." ); } config.initial_cargo_clippy = cargo_clippy; </ins> config.initial_rustc = if let Some(rustc) = rustc { if !flags.skip_stage0_validation { config.check_stage0_version(&rustc, "rustc");

Related discussion:
text: I'm pretty sure it is possible to set custom paths for , & in but not for clippy.
label +T-bootstrap
Code change:
[platform-support]: https://forge.rust-lang.org/platform-support.html <del> ## Installing on Linux or Mac </del> <ins> ## Installing Rust </ins> <del> If we're on Linux or a Mac, all we need to do is open a terminal and type this: </del> <ins> All you need to do on Unix systems like Linux and macOS is open a terminal and type this: </ins> ```bash <del> $ curl -sSf https://static.rust-lang.org/rustup.sh | sh </del> <ins> $ curl https://sh.rustup.rs -sSf | sh </ins> ``` <del> This will download a script, and start the installation. If it all goes well, you’ll see this appear: </del> <ins> It will download a script, and start the installation. If everything goes well, you’ll see this appear: </ins> ```text <del> Rust is ready to roll. </del> <ins> Rust is installed now. Great! </ins> ``` <del> From here, press `y` for ‘yes’, and then follow the rest of the prompts. </del> <ins> Installing on Windows is nearly as easy: download and run [rustup-init.exe]. It will start the installation in a console and present the above message on success. </ins> <del> ## Installing on Windows </del> <ins> For other installation options and information, visit the [install] page of the Rust website. </ins> <del> If you're on Windows, please download the appropriate [installer][install-page]. [install-page]: https://www.rust-lang.org/install.html </del> <ins> [rustup-init.exe]: https://win.rustup.rs [install]: https://www.rust-lang.org/install.html </ins> ## Uninstalling <del> Uninstalling Rust is as easy as installing it. On Linux or Mac, run the uninstall script: </del> <ins> Uninstalling Rust is as easy as installing it: </ins> ```bash <del> $ sudo /usr/local/lib/rustlib/uninstall.sh </del> <ins> $ rustup self uninstall </ins> ``` <del> If we used the Windows installer, we can re-run the `.msi` and it will give us an uninstall option. </del> ## Troubleshooting If we've got Rust installed, we can open up a shell, and type this:

Related discussion:
text: Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Code change:
} } <ins> #[cfg(target_arch = "x86_64")] fn f128() { const_assert!((1f128).to_bits(), 0x3fff0000000000000000000000000000); const_assert!(u128::from_be_bytes(1f128.to_be_bytes()), 0x3fff0000000000000000000000000000); const_assert!((12.5f128).to_bits(), 0x40029000000000000000000000000000); const_assert!(u128::from_le_bytes(12.5f128.to_le_bytes()), 0x40029000000000000000000000000000); const_assert!((1337f128).to_bits(), 0x40094e40000000000000000000000000); const_assert!(u128::from_ne_bytes(1337f128.to_ne_bytes()), 0x40094e40000000000000000000000000); const_assert!((-14.25f128).to_bits(), 0xc002c800000000000000000000000000); const_assert!(f128::from_bits(0x3fff0000000000000000000000000000), 1.0); const_assert!(f128::from_be_bytes(0x3fff0000000000000000000000000000u128.to_be_bytes()), 1.0); const_assert!(f128::from_bits(0x40029000000000000000000000000000), 12.5); const_assert!(f128::from_le_bytes(0x40029000000000000000000000000000u128.to_le_bytes()), 12.5); const_assert!(f128::from_bits(0x40094e40000000000000000000000000), 1337.0); assert_eq!(f128::from_ne_bytes(0x40094e40000000000000000000000000u128.to_ne_bytes()), 1337.0); const_assert!(f128::from_bits(0xc002c800000000000000000000000000), -14.25); // Check that NaNs roundtrip their bits regardless of signalingness // 0xA is 0b1010; 0x5 is 0b0101 -- so these two together clobbers all the mantissa bits // NOTE: These names assume `f{BITS}::NAN` is a quiet NAN and IEEE754-2008's NaN rules apply! const QUIET_NAN: u128 = f128::NAN.to_bits() | 0x0000_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA_AAAA; const SIGNALING_NAN: u128 = f128::NAN.to_bits() ^ 0x0000_5555_5555_5555_5555_5555_5555_5555; const_assert!(f128::from_bits(QUIET_NAN).is_nan()); const_assert!(f128::from_bits(SIGNALING_NAN).is_nan()); const_assert!(f128::from_bits(QUIET_NAN).to_bits(), QUIET_NAN); if !has_broken_floats() { const_assert!(f128::from_bits(SIGNALING_NAN).to_bits(), SIGNALING_NAN); } } </ins> fn main() { <ins> #[cfg(target_arch = "x86_64")] { f16(); f128(); } </ins> f32(); f64(); }

Related discussion:
text: This file is only and : , but we should add the other float types to this test. The change should wait for since that changes some of these semantics (this PR is almost merged). There are probably a handful of tests that only check and but could use updates with the new types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Okay will do that
FYI you can comment to assign yourself an issue
claim
Code change:
return Some(*c); } <del> let mut dist = dist.unwrap_or_else(|| cmp::max(lookup.len(), 3) / 3); </del> <ins> // `fn edit_distance()` use `chars()` to calculate edit distance, so we must // also use `chars()` (and not `str::len()`) to calculate length here. let lookup_len = lookup.chars().count(); let mut dist = dist.unwrap_or_else(|| cmp::max(lookup_len, 3) / 3); </ins> let mut best = None; // store the candidates with the same distance, only for `use_substring_score` current. let mut next_candidates = vec![];

Related discussion:
text: In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.
Code change:
fn f(a: u16, b: &str) {} fn main() { <del> f(0); //~ ERROR E0061 </del> <ins> f(0); //~^ ERROR E0061 //~| NOTE expected 2 parameters //~| NOTE the following parameter types were expected </ins> }

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Code change:
run: src/ci/scripts/install-wix.sh <<: *step <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh <<: *step </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh <<: *step

Related discussion:
text: The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.
Code change:
run: src/ci/scripts/install-wix.sh <<: *step <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh <<: *step </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh <<: *step

Related discussion:
text: I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.
Code change:
<ins> // Checks that naked functions are never inlined. // compile-flags: -O -Zmir-opt-level=2 // ignore-wasm32 #![crate_type = "lib"] #![feature(asm)] #![feature(naked_functions)] #[inline(always)] #[naked] #[no_mangle] pub unsafe extern "C" fn f() { // Check that f has naked and noinline attributes. // // CHECK:       define void @f() unnamed_addr [[ATTR:#[0-9]+]] // CHECK-NEXT:  start: // CHECK-NEXT:    call void asm asm!("", options(noreturn)); } #[no_mangle] pub unsafe fn g() { // Check that call to f is not inlined. // // CHECK-LABEL: define void @g() // CHECK-NEXT:  start: // CHECK-NEXT:    call void @f() f(); } // CHECK: attributes [[ATTR]] = { naked noinline{{.*}} } </ins>

Related discussion:
text: Currently, the compiler is allowed to inline naked functions if it wants to. For a normal function, inlining is fine because the compiler can remove the function prologue/epilogue and the remaining will behave as expected. However for naked functions, the developer provides the prologue/epilogue and those aren't removed by the compiler. This almost surely will result in incorrect behavior. Accordingly I think it would make sense for the compiler to not inline naked functions unless the developer explicitly opted-in.
In the other thread, alistair23 found that
Yes, functions should imply .
Code change:
// through and constrain Pi. let mut subcomponents = smallvec![]; let mut subvisited = SsoHashSet::new(); <del> compute_components_recursive(tcx, ty.into(), &mut subcomponents, &mut subvisited); </del> <ins> compute_alias_components_recursive(tcx, ty, &mut subcomponents, &mut subvisited); </ins> out.push(Component::EscapingAlias(subcomponents.into_iter().collect())); } }

Related discussion:
text: Another regresssion of with a different failure path: It should be fixed by ignoring non-captured lifetimes in: cc label regression-from-stable-to-stable C-bug T-compiler T-types A-impl-trait
Note that fixing this issue is necessary for , but might not be sufficient. I'll investigate more...
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
// through and constrain Pi. let mut subcomponents = smallvec![]; let mut subvisited = SsoHashSet::new(); <del> compute_components_recursive(tcx, ty.into(), &mut subcomponents, &mut subvisited); </del> <ins> compute_alias_components_recursive(tcx, ty, &mut subcomponents, &mut subvisited); </ins> out.push(Component::EscapingAlias(subcomponents.into_iter().collect())); } }

Related discussion:
text: Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
pub fn report_error_if_loans_conflict(&self, old_loan: &Loan<'tcx>, <del> new_loan: &Loan<'tcx>) { </del> <ins> new_loan: &Loan<'tcx>) -> bool { </ins> //! Checks whether `old_loan` and `new_loan` can safely be issued //! simultaneously.

Related discussion:
text: Ran into this when running a fauly tt muncher with ~100 items. We can now compete with C++ in the compiler spew area as well! :-P
Ran into this while demonstrating why you need raw pointers to do a singly-linked-queue: 66 Borrow check errors in this test.
Code change:
fn method(&self) -> impl Trait<Type = impl Sized + '_>; } <ins> trait Trait2 { type Type; fn method(&self) -> impl Trait2<Type = impl Trait2<Type = impl Sized + '_> + '_>; } </ins> fn main() {}

Related discussion:
text: <!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve
Code change:
<ins> // Traits in scope are collected for doc links in field attributes. // check-pass // aux-build: assoc-field-dep.rs extern crate assoc_field_dep; pub use assoc_field_dep::*; #[derive(Clone)] pub struct Struct; pub mod mod1 { pub struct Fields { /// [crate::Struct::clone] pub field: u8, } } pub mod mod2 { pub enum Fields { V { /// [crate::Struct::clone] field: u8, }, } } </ins>

Related discussion:
text: Here is a complete (minimized) reproducer: It can be reproduced with a workspace with two crates "a" and "b" where: The crate "a" depends on the public () crate and its code is: . The crate "b" depends on the workspace crate and its code is: With that setup, the command rightfully succeeds using the stable toolchain. But fails when using the latest (2022-04-25) nightly toolchain. The bug is observable on nightly only (works fine on stable, and beta) : <details<summary<strongBacktrace</strong</summary<p</p</details
Fixed in
Code change:
} } <ins> /// A call to a `panic()` lang item where the first argument is _not_ a `&str`. #[derive(Debug)] pub struct PanicNonStr; impl NonConstOp for PanicNonStr { fn build_error(&self, ccx: &ConstCx<'_, 'tcx>, span: Span) -> DiagnosticBuilder<'tcx> { ccx.tcx.sess.struct_span_err( span, "argument to `panic!()` in a const context must have type `&str`", ) } } </ins> #[derive(Debug)] pub struct RawPtrComparison; impl NonConstOp for RawPtrComparison {

Related discussion:
text: The panic payload of the macro (as passed on to ) is generic, but the CTFE panic support assumes it will always be an . This leads to ICEs: Cc
I guess we could support this, but we'd have to find some way to render the errors. Maybe we need to wait for const traits so we can require const Debug?
Alternatively constck could require the argument to have type .
also requires a
Yeah, the libcore panic machinery does not support non-format-string panics.
Aye, left out the latter of my message. is likely the most common argument to , and it's not unusual with e.g. ; so I agree that waiting for const traits before supporting any other arguments is reasonable.
Im hitting this ICE on stable without feature flag:
Hm indeed, that is interesting: any idea why we go on here after seeing an error? Does this kind of behavior mean any part of CTFE is reachable on stable somehow?
yes. We're not gating CTFE on whether there were stability (or any other static checks) failing. I've been abusing this since 1.0 to demo things on the stable compiler and never got around to fixing it. I don't even know if we have a tracking issue for it.
:rofl: So what would be a possible approach here? Replace such consts by early enough that their MIR never actually gets evaluated? We might as well use this issue, IMO...
That would require us to mutate all MIR and potentially even HIR. Other possible solutions: poison the mir Body if const checks fail (by adding a field like or by just nuking the body by replacing it with ) and thus make allow const evaluation to check if the mir Body failed the checks and bail out before doing anything make the have an field similar to
On second thought, let's leave this issue for the ICE, and make a new one for "we can trigger nightly-only const code on stable because we don't abort compilation early enough":
Given that this ICE is pre-existing, as shown by , can we un-block ? I'd really like to see const_panic stabilized, and this seems like a minor issue to be blocking on.
That comment is an example of accidentally partially exposing an unstable feature on stable -- a separate bug tracked in I don't see how that's an argument for shipping that feature on stable when it is broken.