jiebi/CodeConvo huggingface dataset:
Change:
--> $DIR/issue-39848.rs:8:19 | LL |         if $tgt.has_$field() {} <del> |         --                 - help: try placing this code inside a block: `{ foo(); }` </del> <ins> |         --                 - help: try placing this code inside a block: `{ ) }` </ins> |         | |         this `if` statement has a condition, but no block ...

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
// The type table might not have information for this expression // if it is in a malformed scope. (#66387) if let Some(ty) = self.fcx.typeck_results.borrow().expr_ty_opt(expr) { <ins> if guard_borrowing_from_pattern { // Match guards create references to all the bindings in the pattern that are used // in the guard, e.g. `y if is_even(y) => ...` becomes `is_even(*r_y)` where `r_y` // is a reference to `y`, so we must record a reference to the type of the binding. let tcx = self.fcx.tcx; let ref_ty = tcx.mk_ref( // Use `ReErased` as `resolve_interior` is going to replace all the regions anyway. tcx.mk_region(ty::RegionKind::ReErased), ty::TypeAndMut { ty, mutbl: hir::Mutability::Not }, ); self.record(ref_ty, scope, Some(expr), expr.span, guard_borrowing_from_pattern); } </ins> self.record(ty, scope, Some(expr), expr.span, guard_borrowing_from_pattern); } else { self.fcx.tcx.sess.delay_span_bug(expr.span, "no type for node");

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</detailsThis is the most minimal example I could find, it needs tokio with the features "macro" and "sync". While this error occured on Nightly I could also reproduce this on stable (as far back as on 1.39, didn't test beyond that because my build started failing because of other reasons) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is very reminiscent of (await in if guard in match statement)
MCVE: Yeah, very .
Thank you for reducing this further. Totally forgot that I could just declare my own async function this way! But I do understand correctly that the linked example is just related, not the same? (Since it's still occuring in latest nightly and the linked issue seemes to be already fixed)
Yeah, just related - my immediate guess is this is some case that was missed in the fix for that issue. The difference appears to be that is used in a index expression after the await instead of some other way.
Another example: Any usage of in the if guard after the that does not cause to be autorefed (like just from the MCVE would) appears to trigger the ICE.
claim
Assigning as and removing .
Change:
return } <del> // there's no implemented traits, so lets suggest some traits to implement </del> <ins> let type_is_local = type_derefs_to_local(fcx, span, rcvr_ty); // there's no implemented traits, so lets suggest some traits to // implement, by finding ones that have the method name, and are // legal to implement. </ins> let mut candidates = all_traits(fcx.ccx) <del> .filter(|info| trait_method(tcx, info.def_id, method_name).is_some()) </del> <ins> .filter(|info| { // we approximate the coherence rules to only suggest // traits that are legal to implement by requiring that // either the type or trait is local. Multidispatch means // this isn't perfect (that is, there are cases when // implementing a trait would be legal but is rejected // here). (type_is_local || ast_util::is_local(info.def_id)) && trait_method(tcx, info.def_id, method_name).is_some() }) </ins> .collect::<Vec<_>>(); if candidates.len() > 0 {

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
use rustc_middle::ty::query::{ExternProviders, Providers}; use rustc_middle::ty::subst::{GenericArgKind, SubstsRef}; use rustc_middle::ty::Instance; <del> use rustc_middle::ty::{SymbolName, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, SymbolName, TyCtxt}; </ins> use rustc_session::config::CrateType; use rustc_target::spec::SanitizerSet;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim
Change:
use rustc_middle::ty::query::{ExternProviders, Providers}; use rustc_middle::ty::subst::{GenericArgKind, SubstsRef}; use rustc_middle::ty::Instance; <del> use rustc_middle::ty::{SymbolName, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, SymbolName, TyCtxt}; </ins> use rustc_session::config::CrateType; use rustc_target::spec::SanitizerSet;

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
Change:
for debug_info in body.var_debug_info.iter_mut() { if let VarDebugInfoContents::Place(place) = &mut debug_info.value { let mut new_projections: Option<Vec<_>> = None; <del> let mut last_deref = 0; for (i, (base, elem)) in place.iter_projections().enumerate() { </del> <ins> for (base, elem) in place.iter_projections() { </ins> let base_ty = base.ty(&body.local_decls, tcx).ty; if elem == PlaceElem::Deref && base_ty.is_box() { <del> let new_projections = new_projections.get_or_insert_default(); </del> <ins> // Clone the projections before us, since now we need to mutate them. let new_projections = new_projections.get_or_insert_with(|| base.projection.to_vec()); </ins> let (unique_ty, nonnull_ty, ptr_ty) = build_ptr_tys(tcx, base_ty.boxed_ty(), unique_did, nonnull_did); <del> new_projections.extend_from_slice(&base.projection[last_deref..]); </del> new_projections.extend_from_slice(&build_projection( unique_ty, nonnull_ty, ptr_ty, )); new_projections.push(PlaceElem::Deref); <del> last_deref = i; </del> <ins> } else if let Some(new_projections) = new_projections.as_mut() { // Keep building up our projections list once we've started it. new_projections.push(elem); </ins> } } <del> if let Some(mut new_projections) = new_projections { new_projections.extend_from_slice(&place.projection[last_deref..]); </del> <ins> // Store the mutated projections if we actually changed something. if let Some(new_projections) = new_projections { </ins> place.projection = tcx.mk_place_elems(&new_projections); } }

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</detailsthis was at the end of the error <pi have put a comment in the code where the problematic line is, the problem could be caused by async trait object method in ResourceLoader::startloading<bri am using asynctrait crate<brhere is the library code that the problematic code uses<brthe ResourceLoader trait is at the end </prustc-ice-2024-08-02T150352-!
Change:
--> $DIR/ub-wide-ptr.rs:135:5 | LL |     mem::transmute::<_, &dyn Trait>((&92u8, 0usize)) <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ null pointer is not allowed for this operation </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ null pointer is not a valid pointer for this operation </ins> error[E0080]: could not evaluate static initializer --> $DIR/ub-wide-ptr.rs:139:5

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim
Change:
for path in files { writeln!(file, "{}:", path)?; } <ins> // Emit special comments with information about accessed environment variables. let env_depinfo = sess.parse_sess.env_depinfo.borrow(); if !env_depinfo.is_empty() { let mut envs: Vec<_> = env_depinfo .iter() .map(|(k, v)| (escape_dep_env(*k), v.map(escape_dep_env))) .collect(); envs.sort_unstable(); writeln!(file)?; for (k, v) in envs { write!(file, "# env-dep:{}", k)?; if let Some(v) = v { write!(file, "={}", v)?; } writeln!(file)?; } } </ins> Ok(()) })();

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
<ins> fn main() { 2: n([u8; || 1]) //~^ ERROR cannot find type `n` in this scope //~| ERROR mismatched types } </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting the error "cannot find type in this scope", so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed since , cc
Assigning as and removing .
Another input with a slightly different error message: <details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-07-26 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in . cc
No longer ICEs since
Change:
<ins> error[E0308]: mismatched types --> $DIR/mismatched-types-issue-126222.rs:7:18 | LL |             x => dbg!(x), |                  ^^^^^^^ expected `()`, found integer | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) help: you might have meant to return this value | LL |             x => return dbg!(x), |                  ++++++ error[E0308]: mismatched types --> $DIR/mismatched-types-issue-126222.rs:15:17 | LL |                 dbg!(x) |                 ^^^^^^^ expected `()`, found integer | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) help: you might have meant to return this value | LL |                 return dbg!(x) |                 ++++++ error[E0308]: mismatched types --> $DIR/mismatched-types-issue-126222.rs:23:18 | LL |             _ => dbg!(1) |                  ^^^^^^^ expected `()`, found integer | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) help: you might have meant to return this value | LL |             _ => return dbg!(1) |                  ++++++ error[E0308]: mismatched types --> $DIR/mismatched-types-issue-126222.rs:30:19 | LL |             _ => {dbg!(1)} |                   ^^^^^^^ expected `()`, found integer | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) help: you might have meant to return this value | LL |             _ => {return dbg!(1)} |                   ++++++ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
when using i even got this suggestion recommending i return DefKind from the GlobalCtxt::enter closure, which isn't even remotely the right type. it also seems to only show up when using macros? all around quite strange. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
env, ffi::{OsStr, OsString}, fs::{self, File}, <del> io::{BufRead, BufReader, ErrorKind}, </del> <ins> io::{BufRead, BufReader, BufWriter, ErrorKind, Write}, </ins> path::{Path, PathBuf}, process::{Command, Stdio}, };

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:
<ins> error: items in `extern` blocks cannot use non-ascii identifiers --> $DIR/feature-gate-non_ascii_idents.rs:30:8 | LL | extern "C" { | ---------- in this `extern` block LL |     fn qüx(); |        ^^^ | = note: This limitation may be lifted in the future; see issue #83942 <https://github.com/rust-lang/rust/issues/83942> for more information </ins> error[E0658]: non-ascii idents are not fully supported --> $DIR/feature-gate-non_ascii_idents.rs:1:22 |

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
Change:
tracked!(profile_emit, Some(PathBuf::from("abc"))); tracked!(profile_sample_use, Some(PathBuf::from("abc"))); tracked!(profiler_runtime, "abc".to_string()); <del> tracked!(relax_elf_relocations, Some(false)); </del> <ins> tracked!(relax_elf_relocations, Some(true)); </ins> tracked!(relro_level, Some(RelroLevel::Full)); tracked!(remap_cwd_prefix, Some(PathBuf::from("abc"))); tracked!(report_delayed_bugs, true);

Discussion:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do).

To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.