jiebi/CodeConvo huggingface dataset:
Change:
.find(|ur_vid| self.eval_equal(vid, **ur_vid)) .and_then(|ur_vid| self.definitions[*ur_vid].external_name) .unwrap_or(infcx.tcx.lifetimes.re_erased), <ins> ty::RePlaceholder(_) => ty::Region::new_error_with_message( infcx.tcx, concrete_type.span, "hidden type contains placeholders, we don't support higher kinded opaques yet", ), </ins> _ => region, }); debug!(?universal_concrete_type);

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })', 'error: internal compiler error: unexpected region kind in opaque type: RePlaceholder(!2BoundRegion { var: 0, kind: BrNamed(DefId(0:12 ~ 9DABD1FCA6B4214B1AFB7E3E0DCCB52B1F226FCDBDC62026B721AA5FB17BF76D[c411]::call::'any), 'any) })' File: --auto-reduced (treereduce-rust): original: 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: [mirborrowck] borrow-checking [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc could be related to
yea I have just locally started hitting this in tests/ui/impl-trait/impl-fn-predefined- while rebasing
Change:
} _ => return Err(CastError::NonScalar), }; if let ty::Adt(adt_def, _) = *self.expr_ty.kind() { if adt_def.did().krate != LOCAL_CRATE { if adt_def.variants().iter().any(VariantDef::is_field_list_non_exhaustive) {

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. --: On playgrounds it seemed to affect and for , and . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like it also happens without the re-borrow, but with a different error. <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2021-11-14 found 7 bors merge commits in the specified range commit[0] 2021-11-12: Auto merge of - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr commit[1] 2021-11-13: Auto merge of - workingjubilee:use-simd, r=MarkSimulacrum commit[2] 2021-11-13: Auto merge of - jfrimmel:rtcopychecks, r=Mark-Simulacrum commit[3] 2021-11-13: Auto merge of - mystor:expandliteral, r=petrochenkov commit[4] 2021-11-13: Auto merge of - the8472:privatize-the-means-of-rawvec-production, r=joshtriplett commit[5] 2021-11-13: Auto merge of - jhpratt:stabilize-constrawptrderef, r=oli-obk commit[6] 2021-11-13: Auto merge of - mfrw:mfrw/librustdoc, r=GuillaumeGomez ERROR: no CI builds available between and within last 167 days
Regression in nightly-2019-06-17 found 7 bors merge commits in the specified range commit[0] 2019-06-15: Auto merge of - RalfJung:cfg-if,

r=alexcrichton commit[1] 2019-06-16: Auto merge of - Centril:rollup-3p3m2fu, r=Centril commit[2] 2019-06-16: Auto merge of - matthewjasper:optimize-false-edges, r=pnkfelix commit[3] 2019-06-16: Auto merge of - chansuke:separate-unit-tests, r=petrochenkov commit[4] 2019-06-16: Auto merge of - nikomatsakis:trait-caching-perf-3, r=pnkfelix commit[5] 2019-06-16: Auto merge of - glaubitz:sparc64-ffi-abi, r=petrochenkov commit[6] 2019-06-16: Auto merge of - Centril:stabilize-underscoreconstnames, r=petrochenkov ERROR: no CI builds available between and within last 167 days
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This also returns ICE, but ICE message varies between rustc version.
Change:
condition: cache.x86_64_dlltool, ignore_reason: "ignored when dlltool for x86_64 is not present", }, <ins> Need { name: "needs-git-hash", condition: config.git_hash, ignore_reason: "ignored when git hashes have been omitted for building", }, </ins> ]; let (name, comment) = match ln.split_once([':', ' ']) {

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim
Change:
let sf = &lines.file; let mut prev_hi = sm.lookup_char_pos(bounding_span.lo()); prev_hi.col = CharPos::from_usize(0); <del> let mut prev_line = sf.get_line(lines.lines[0].line_index); </del> <ins> let mut prev_line = lines.lines.get(0).and_then(|line0| sf.get_line(line0.line_index)); </ins> let mut buf = String::new(); for part in &substitution.parts {

Discussion:
Problem returns invalid span data, particularly and are set to 0, though . This happens with a completly empty file. Tested on the following cargo version: Whilst on the stable version the returned span array is empty: Steps Now you can see invalid span in file. I've already created and formatted and files with the output of different cargo versions. Here are the crutial differences and Context
Moved to rust-lang/rust, where diagnostics live. Seems to be caused by , cc
additional info: The regression is also present on the older version of nightly rustc: This was the version where I initially spotted the issue, then updated and rechecked, but it was still present in .
Probably caused by
triage: P-high. Assigning to self.
Change:
target_os = "macos", target_os = "ios")))] pub fn created(&self) -> io::Result<SystemTime> { <ins> cfg_has_statx! { if let Some(ext) = &self.statx_extra_fields { return if (ext.stx_mask & libc::STATX_BTIME) != 0 { Ok(SystemTime::from(libc::timespec { tv_sec: ext.stx_btime.tv_sec as libc::time_t, tv_nsec: ext.stx_btime.tv_nsec as _, })) } else { Err(io::Error::new( io::ErrorKind::Other, "creation time is not available for the filesystem", )) }; } } </ins> Err(io::Error::new(io::ErrorKind::Other, "creation time is not available on this platform  currently"))

Discussion:
First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?
Change:
"checksum precomputed-hash 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "cdf1fc3616b3ef726a847f2cd2388c646ef6a1f1ba4835c2629004da48184150" "checksum procedural-masquerade 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "c93cdc1fb30af9ddf3debc4afbdb0f35126cbd99daa229dd76cdd5349b41d989" "checksum psapi-sys 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "abcd5d1a07d360e29727f757a9decb3ce8bc6e0efa8969cfaad669a8317a2478" <del> "checksum pulldown-cmark 0.0.14 (registry+https://github.com/rust-lang/crates.io-index)" = "d9ab1e588ef8efd702c7ed9d2bd774db5e6f4d878bb5a1a9f371828fbdff6973" </del> "checksum pulldown-cmark 0.0.15 (registry+https://github.com/rust-lang/crates.io-index)" = "378e941dbd392c101f2cb88097fa4d7167bc421d4b88de3ff7dbee503bc3233b" "checksum pulldown-cmark 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a656fdb8b6848f896df5e478a0eb9083681663e37dcb77dd16981ff65329fe8b" "checksum quick-error 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "eda5fe9b71976e62bc81b781206aaa076401769b2143379d3eb2118388babac4"

Discussion:
generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes
Change:
strings are not null-terminated and can contain null bytes. Rust has two main types of strings: `&str` and `String`. Let’s talk about <del> `&str` first. These are called ‘string slices’. String literals are of the type `&'static str`: </del> <ins> `&str` first. These are called ‘string slices’. A string slice has a fixed size, and cannot be mutated. It is a reference to a sequence of UTF-8 bytes. </ins> ```rust let greeting = "Hello there."; // greeting: &'static str ``` <del> This string is statically allocated, meaning that it’s saved inside our compiled program, and exists for the entire duration it runs. The `greeting` binding is a reference to this statically allocated string. String slices have a fixed size, and cannot be mutated. </del> <ins> `"Hello there."` is a string literal and its type is `&'static str`. A string literal is a string slice that is statically allocated, meaning that it’s saved inside our compiled program, and exists for the entire duration it runs. The `greeting` binding is a reference to this statically allocated string. Any function expecting a string slice will also accept a string literal. </ins> String literals can span multiple lines. There are two forms. The first will include the newline and the leading spaces:

Discussion:
From "Strings" chapter: The problem is that a beginner who reads these lines can make a false conclusion that "string slice" and "string literal" mean the same thing, and string slices always has a static lifetime. Comment from newcomer:
To be clear: a string literal is just a string slice that lives forever (because it's a pointer into the binary's rodata or whatever).
yep, but looks like it is not obvious for newcomers. I think we should make these lines in the book more clear.
Yep, always a great thing to do! Just clarifying for whoever wants to fix this up.
Change:
} fn check_pat(&mut self, cx: &LateContext<'_, '_>, p: &hir::Pat<'_>) { <del> if let &PatKind::Binding(_, _, ident, _) = &p.kind { </del> <ins> if let &PatKind::Binding(_, hid, ident, _) = &p.kind { if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } } return; } } </ins> self.check_snake_case(cx, "variable", &ident); } }

Discussion:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense.

Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?
Change:
run_passes_inner(tcx, body, passes, phase_change, true); } <ins> pub fn should_run_pass<'tcx, P>(tcx: TyCtxt<'tcx>, pass: &P) -> bool where P: MirPass<'tcx> + ?Sized, { let name = pass.name(); let overridden_passes = &tcx.sess.opts.unstable_opts.mir_enable_passes; let overridden = overridden_passes.iter().rev().find(|(s, _)| s == &*name).map(|(_name, polarity)| { trace!( pass = %name, "{} as requested by flag", if *polarity { "Running" } else { "Not running" }, ); *polarity }); overridden.unwrap_or_else(|| pass.is_enabled(&tcx.sess)) } </ins> fn run_passes_inner<'tcx>( tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>,

Discussion:
While trying to build a test for , I renamed my test file and it stopped ICEing. I have no idea what's happening here. Create a file with this contents called Then This compiles fine: But this ICEs:
We skip calling by comparing def-path hashes. The def-path hash provides a total order on MIR bodies that respects incremental compilation, and avoids a potentially costly query. OTOH, it depends on the crate name, which is the file name in your example. If you add a somewhere, that should be reproducible.
Setting the crate name would stabilize this for now, but any change to the hash algorithm could cause this test to suddenly pass, even if the compiler regresses in its behavior. Is there a way around that problem?
As someone who has changed the hash algorithm before, a comment in the file that says you might have to fiddle with the crate name to find something where that check works (including a link to this issue) might be enough if there's no other option.
I'm not concerned about the test suddenly failing, I'm concerned about it suddenly passing when it shouldn't.
I can't reproduce the MCVE in your opening comment. However, if I rename the file to then it emits an ICE (which I suspect is the same you reported here, is it? <details</detailsTo summarize: :heavycheckmark: :heavycheckmark: :skull: I'm really puzzled. Any idea? :thinking: EDIT: worth mentioning I'm on the latest nightly:
For testing purposes? Repeat the test a number of times to ensure that it is unlikely that it will pass by an accident.
Yes, that is the ICE in question, and your difficulty in reproducing this underscores the problem here. Any ICE that relies on MIR inlining within a crate (as opposed to inlining a function from another crate) may stop reproducing basically at any time. I believe this is the same reason that bisects to unrelated commits.
Change:
if !t!(member.unpack_in(dst)) { panic!("path traversal attack ??"); } <ins> if let Some(record) = &mut recorded_entries { t!(writeln!(record, "{}", short_path.to_str().unwrap())); } </ins> let src_path = dst.join(original_path); if src_path.is_dir() && dst_path.exists() { continue; } t!(fs::rename(src_path, dst_path)); } <del> t!(fs::remove_dir_all(dst.join(directory_prefix))); </del> <ins> let dst_dir = dst.join(directory_prefix); if dst_dir.exists() { t!(fs::remove_dir_all(&dst_dir), format!("failed to remove {}", dst_dir.display())); } </ins> } /// Returns whether the SHA256 checksum of `path` matches `expected`.

Discussion:
cc I tried this: I expected to see this happen: The tests pass. Instead, this happened: The tests fail: These tests are pretty complicated but the error message looks correct: I'm not sure why both files are there and particularly why they have different hashes. shows that is being downloaded from CI, and I guess the is coming from somewhere - maybe we should clear the directory before doing that? <!-- 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. --HEAD is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Ok, it turns out both versions are coming from CI: I am ... surprised this hasn't broken anything else? I don't know why only this specific test would be failing.
The difference between this test and others is that somehow in other tests knows ahead of time which hash it should use: for the allocator tests, it doesn't know, and gives an ambiguity error:
ok, here's a minimal reproducer: I think what's going on is for the working tests, the implicit injected by the compiler also loads libc, because std depends on libc: Then, when the compiler sees , it's already seen the version depends on and resolves the ambiguity by reusing that crate. But for the failing test, we never load std, so we don't have a pre-existing hash to default to, so it gives a hard ambiguity error.
Change:
fn main() { const FOO = "hello" + 1; //~ ERROR cannot add `{integer}` to `&str` <del> //~^ ERROR cannot add `{integer}` to `&str` </del> <ins> //~^ missing type for `const` item </ins> println!("{}", FOO); }

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
pub fn offset(&self, i: usize) -> Size { match *self { <del> FieldPlacement::Union(count) => { assert!(i < count, "Tried to access field {} of union with {} fields", i, count); Size::ZERO }, </del> <ins> FieldPlacement::Union(_) => Size::ZERO, </ins> FieldPlacement::Array { stride, count } => { let i = i as u64; assert!(i < count);

Discussion:
I get the following internal compiler error with rustc nightly: To reproduce, just checkout the repo at the following commit: Run:
Can you please provide a minimized example that would fit in the playground without any dependencies? We would also appreciate a backtrace.
Sorry for forgetting the backtrace, here we go: Regarding a minimized example, I would really like to provide you one, but I did not change any code. I just updated the nightly compiler. The latest stable compiles this code without any problems.
Sure; it's just substantially more difficult to fix a bug when the input is large as compared to just a few lines of code you can put in a file (and in the playground!). :) Reports with a minimal snippet tend to get fixed much faster and we sorta need a regression test as well.
cc
Did you try the beta compiler? Does it work there?
Okay, I tried to find the problem and to reproduce it. I failed at reproducing :( However, I found the line If I remove this call to it does not crash. This call is implemented in the following monstrous impl block: I somehow suspect that the where clause could be the reason for it. Sorry for not being able to reduce it anymore! I'm currently testing the beta channel and will report back when I know more.
Beta works for me.
I downgraded to "rustc 1.40.0-nightly ( 2019-10-13)" and that compiles the crate without any problems.
triage: P-high. self-assigning. removing nomination tag.
Minimal example: . It works on stable and on beta; it ICEs on nightly.
Curiously this does not reproduce with instead of . cc
I believe this is an assert at my request - it already existed in miri, but was missing from the original implementation in .
can we remove the assertion for now?
Oops, this slipped into beta ( was on vacation and I forgot about it completely).
(to be fair, it was assigned to me, and I just kept letting it slip on my own priority list as well...)
reassigning to based on feedback from compiler team
This regressed
Change:
LDFLAGS=$LLVM_LDFLAGS LLVM_FLAGS="$LLVM_TARGETS $LLVM_OPTS $LLVM_BUILD  <del> $LLVM_HOST $LLVM_TARGET" </del> <ins> $LLVM_HOST $LLVM_TARGET --with-python=$CFG_PYTHON" </ins> msg "configuring LLVM with:" msg "$LLVM_FLAGS"

Discussion:
I did drop our patch to fix python detection, thinking it was fixed upstream. It appears not to be and reapplying our patch to fix python detection does not appear to fix the problem.
It may not be related to python. Could just be failing in the vicinity of the python test.
the way I end up dealing with this is making a temp directory and putting another python symlink in with it. So perhaps Rust could detect if is python3 or if only exists and do that before it builds LLVM. That would avoid needing to patch LLVM too. It looks like LLVM has a variable in , so perhaps Rust could be using that somehow.
I can confirm that this also occurs in OS X.
Switching to python 2.7 seemed to allow it to build - I was on python 3.3. For those using MacPorts: .
Fixed.