jiebi/CodeConvo huggingface dataset:
Change:
// Opaque types can't have field projections, but we can instead convert // the current place in-place (heh) to the hidden type, and then apply all // follow up projections on that. <del> if node_ty != place_ty && place_ty.has_opaque_types() { </del> <ins> if node_ty != place_ty && matches!(place_ty.kind(), ty::Alias(ty::Opaque, ..)) { </ins> projections.push(Projection { kind: ProjectionKind::OpaqueCast, ty: node_ty }); } projections.push(Projection { kind, ty });

Discussion:
https://crater- https://crater- https://crater-
Might be related to
I've tried the first 2 crates (bonedaddy.ellidri and edu-sync), they compile on the current stable fail to compile on beta and nightly. Provisionally assigning P-high waiting for more investigation (). label -I-prioritize +P-high +T-compiler
bisected to commit , where in this commit originates the issue: Regression in i.e. rollup PR (Implement proposed API for ) (Simplify computation of killed borrows) (More nits) (add note for non-exhaustive matches with guards) (Fix invalid HTML DIV tag used in HEAD) (add myself to review for t-types stuff) label -e-needs-bisection
Bisection probably leads to cc TIL to look at the results, they help getting more context. They told me tha PR is actually commit
I'll take a look at this after RustConf.
Is it possible the bisection contained an error? I'm not seeing any possible connection. The errors seem unrelated, is not used anywhere in my PR, and is not even present in any of the three linked logs.
Ok, I give up on reproducing using the crate (in the latest nightlies the error changed, I can't track the original error anymore). So I've started again using the crate I now have a stable reproducible. I am now a bit more confident the regression is in (specifically ) cc (I see in that patch some code that is in the stacktraces). sorry for the ping and thanks for pointing me into the right direction :)
No worries! Someone mentioned that it may have been incorrect at RustConf, but I wanted to have a chance to look into it myself before saying anything. I'll be unsubscribing from this issue; please ping if something needs my attention :)
small, but not yet minimal repro. Should be good enough for the test suite. I'm looking into a fix now.
I reverted all changes from and it does not appear to change behaviour. trying a local bisect on the minimal repro. edit: hmm weird, it also points to that PR. Trying again edit2: ok now it works, weird
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn windows(&self, size: usize) -> Windows<'_, T> { <del> assert!(size != 0); </del> <ins> assert_ne!(size, 0); </ins> Windows { v: self, size } }

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
} fn run(self, builder: &Builder<'_>) -> PathBuf { <del> builder </del> <ins> let cargo_bin_path = builder </ins> .ensure(ToolBuild { compiler: self.compiler, target: self.target,

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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
<ins> fn main() { a(_:b:,) //~^ ERROR: expected identifier, found reserved identifier `_` //~| ERROR: expected type, found `,` //~| ERROR: expected type, found `,` } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-12-01 and stable 1.57 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly simpler example not using attributes the name outside the parentheses and the name between the two colons can be arbitrary, the parentheses, underscore, and comma all appear to matter
I found a fix for this, but currently i am only emitting a suggestion for transforming the input into a struct: how do you guys think should i do a function suggestion? Should i just remove the parameter? Or should i remove the function suggestion altogether and just emit the struct suggestion? or something completely different? here is an example how the same diagnostic's output looks like for a more sane input:
I wouldn't give much thought to suggestions, as it's unlikely that a human will enter this input. So I would just remove the suggestions if they are most likely wrong. For example the struct suggestion is invalid code because structs cannot use as a field name (right?). And I'm not sure what kind of code would use two colons , it's most likely a weird typo, so a generic "unexpected token" error should be fine.
claim
Change:
<ins> // run-rustfix #![allow(dead_code, unused_variables)] fn foo1(bar: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo2(_bar: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn foo3(_: &str) {} //~^ ERROR the size for values of type `str` cannot be known at compilation time //~| HELP the trait `Sized` is not implemented for `str` //~| HELP unsized fn params are gated as an unstable feature //~| HELP function arguments must have a statically known size, borrowed types always have a known size fn main() {} </ins>

Discussion:
() Errors: Applying the suggestion leads to yet more errors. The new errors do suggest using , but they still suggest invalid code: After applying the new suggestions, I get: This seems likely to send new users in circles. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning and removing as in the prioritization working group.
I've bisected to this nightly range: +nightly-2020-07-12-x8664-unknown-linux-gnu =old error msg +nightly-2020-07-26-x8664-unknown-linux-gnu =new error message (I cannot bisect further because in between of that range I cannot install nightlies :man_shrugging: )
Funny enough, when using as variable name, the suggestion will get displayed correctly:
This seems to be fixed on nighlty, but not on beta... somewhere between ... Fixed in Fixed by So this can be closed
But, as a sidenote: How could this ever be commited to master? I mean, it's obviosly wrong so say :/ I hope, that in the future the review process can be improved to detect such errors early on. The error was introduced in , where the test has been adapted to match the wrong syntax, but nobody has seen this :( Let's hope in the future it will get noticed right away
It looks like that PR caused a bunch of small diagnostics changes, so the reviewers probably just missed that bug.
Assigning myself for adding a test. claim
Change:
let func_ty = func.ty(body, tcx); if let ty::FnDef(callee, args) = *func_ty.kind() { <del> let normalized_args = tcx.normalize_erasing_regions(param_env, args); </del> <ins> let Ok(normalized_args) = tcx.try_normalize_erasing_regions(param_env, args) else { return false; }; </ins> let (callee, call_args) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, normalized_args) {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: Version 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc
Change:
} #[test] <ins> fn test_exp() { assert_eq!(1.0, 0.0f32.exp()); assert_approx_eq!(2.718282, 1.0f32.exp()); assert_approx_eq!(148.413162, 5.0f32.exp()); let inf: f32 = Float::infinity(); let neg_inf: f32 = Float::neg_infinity(); let nan: f32 = Float::nan(); assert_eq!(inf, inf.exp()); assert_eq!(0.0, neg_inf.exp()); assert!(nan.exp().is_nan()); } #[test] fn test_exp2() { assert_eq!(32.0, 5.0f32.exp2()); assert_eq!(1.0, 0.0f32.exp2()); let inf: f32 = Float::infinity(); let neg_inf: f32 = Float::neg_infinity(); let nan: f32 = Float::nan(); assert_eq!(inf, inf.exp2()); assert_eq!(0.0, neg_inf.exp2()); assert!(nan.exp2().is_nan()); } #[test] </ins> fn test_asinh() { assert_eq!(0.0f32.asinh(), 0.0f32); assert_eq!((-0.0f32).asinh(), -0.0f32);

Discussion:
This succeeds and shouldn't. In , is also calling . Might just have to add a 2...
And tests probably...
Change:
} else { ("fn` or `struct", "function or struct", true) }; <del> self.consume_block(token::Brace); </del> let msg = format!("missing `{}` for {} definition", kw, kw_name); let mut err = self.diagnostic().struct_span_err(sp, &msg); if !ambiguous { <ins> self.consume_block(token::Brace); </ins> let suggestion = format!("add `{}` here to parse `{}` as a public {}", kw, ident,

Discussion:
Hi, I got the compiler to panic with this invalid code: The panic does not happen when the code is outside . Happens on Backtrace : and also on Backtrace :
First appeared in 1.33.0, 1.32.0 gives this error:
Change:
this = "the implicit `Sized` requirement on this type parameter"; } if let Some(hir::Node::TraitItem(hir::TraitItem { <del> ident, </del> <ins> generics, </ins> kind: hir::TraitItemKind::Type(bounds, None), .. })) = tcx.hir().get_if_local(item_def_id)

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:
self.found = Some(NonStructuralMatchTy::Param); return true; // Stop visiting. } <ins> ty::Dynamic(..) => { self.found = Some(NonStructuralMatchTy::Dynamic); return true; // Stop visiting. } </ins> ty::RawPtr(..) => { // structural-match ignores substructure of // `*const _`/`*mut _`, so skip `super_visit_with`.

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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
self.found = Some(NonStructuralMatchTy::Param); return true; // Stop visiting. } <ins> ty::Dynamic(..) => { self.found = Some(NonStructuralMatchTy::Dynamic); return true; // Stop visiting. } </ins> ty::RawPtr(..) => { // structural-match ignores substructure of // `*const _`/`*mut _`, so skip `super_visit_with`.

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
bb4: { StorageDead(_4);                 // scope 0 at $DIR/while-storage.rs:13:9: 13:10 <del> goto -> bb6;                     // scope 0 at $DIR/while-storage.rs:1:1: 1:1 </del> <ins> goto -> bb6;                     // scope 0 at no-location </ins> } bb5: {

Discussion:
Sysroot has been compiled using to get set. Otherwise it is hard to guess a defid with encoded mir, now it is just taking the first exported symbol from:
I used to read the mir.
I think these are and printed as . If so it would be less confusing if the debug impl of would say or something like that instead.
I'm unsure how to reproduce the environment to reproduce this bug. It's easy to adjust the debug printing for , but without a test for that I'm not sure how to test it
Change:
span, "the `Self` constructor can only be used with tuple or unit structs", ); <del> if let Some(adt_def) = adt_def { </del> <ins> if let Some(adt_def) = ty.ty_adt_def() { </ins> match adt_def.adt_kind() { AdtKind::Enum => { err.help("did you mean to use one of the enum's variants?");

Discussion:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?
Change:
use crate::clean::RenderedLink; use crate::doctest; <ins> use crate::html::escape::Escape; </ins> use crate::html::highlight; use crate::html::toc::TocBuilder;

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. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
fn trans_crate(sess: session::session, crate: @ast::crate, tcx: ty::ctxt, output: str, amap: ast_map::map, mut_map: mut::mut_map, copy_map: alias::copy_map) -> ModuleRef { <del> let llmod = str::as_buf("rust_out", {|buf| </del> <ins> let sha = std::sha1::mk_sha1(); let link_meta = link::build_link_meta(sess, *crate, output, sha); let llmod = str::as_buf(link_meta.name, {|buf| </ins> llvm::LLVMModuleCreateWithNameInContext (buf, llvm::LLVMGetGlobalContext()) });

Discussion:
For compatibility with clang and for debugging convenience, should disassemble the bitcode.
Change:
p.destroy(); // ...and nor should this (and nor should the destructor) } <del> #[cfg(unix)] // there is no way to sleep on windows from inside libcore... </del> fn test_destroy_actually_kills(force: bool) { <del> let path = Path(fmt!("test/core-run-test-destroy-actually-kills-%?.tmp", force)); os::remove_file(&path); </del> <ins> #[cfg(unix)] static BLOCK_COMMAND: &'static str = "cat"; </ins> <del> let cmd = fmt!("sleep 5 && echo MurderDeathKill > %s", path.to_str()); let mut p = run::start_program("sh", [~"-c", cmd]); </del> <ins> #[cfg(windows)] static BLOCK_COMMAND: &'static str = "cmd"; </ins> <del> p.destroy(); // destroy the program before it has a chance to echo its message </del> <ins> #[cfg(unix)] fn process_exists(pid: libc::pid_t) -> bool { run::program_output("ps", [~"-p", pid.to_str()]).out.contains(pid.to_str()) } </ins> <del> unsafe { // wait to ensure the program is really destroyed and not just waiting itself libc::sleep(10); </del> <ins> #[cfg(windows)] fn process_exists(pid: libc::pid_t) -> bool { use libc::types::os::arch::extra::DWORD; use libc::funcs::extra::kernel32::{CloseHandle, GetExitCodeProcess, OpenProcess}; use libc::consts::os::extra::{FALSE, PROCESS_QUERY_INFORMATION, STILL_ACTIVE }; unsafe { let proc = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid as DWORD); if proc.is_null() { return false; } // proc will be non-null if the process is alive, or if it died recently let mut status = 0; GetExitCodeProcess(proc, &mut status); CloseHandle(proc); return status == STILL_ACTIVE; } </ins> } <del> // the program should not have had chance to echo its message assert!(!path.exists()); </del> <ins> // this program will stay alive indefinitely trying to read from stdin let mut p = run::start_program(BLOCK_COMMAND, []); assert!(process_exists(p.get_id())); if force { p.force_destroy(); } else { p.destroy(); } assert!(!process_exists(p.get_id())); </ins> } #[test] <del> #[cfg(unix)] </del> fn test_unforced_destroy_actually_kills() { test_destroy_actually_kills(false); } #[test] <del> #[cfg(unix)] </del> fn test_forced_destroy_actually_kills() { test_destroy_actually_kills(true); }

Discussion:
Unit tests should not be doing multi-second sleeps as this is bad for turnaround during development.
Fair enough, I will try to get around to looking at this.
Done.
Change:
} } <ins> // Drop `--error-format json` because despite our desire for json messages // from Cargo we don't want any from rustc itself. if let Some(n) = args.iter().position(|n| n == "--error-format") { args.remove(n); args.remove(n); } </ins> // Detect whether or not we're a build script depending on whether --target // is passed (a bit janky...) let target = args.windows(2)

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:
let ty_fn_ptr_from = tcx.safe_to_unsafe_fn_ty(fn_sig); <del> if let Err(terr) = self.eq_types( *ty, </del> <ins> if let Err(terr) = self.sub_types( </ins> ty_fn_ptr_from, <ins> *ty, </ins> location.to_locations(), ConstraintCategory::Cast { unsize_to: None }, ) {

Discussion:
I tried this code: I expected to see it work. Instead, this happened: This regressed in This only happens when coercing from safe to unsafe, not unsafe to unsafe or safe to safe. I probably forgot something about how we construct the adjustment from unsafe to safe fn.