jiebi/CodeConvo huggingface dataset:
Change:
} } <del> check_struct_pat_fields(pcx, span, path, fields, class_fields, struct_id, </del> <ins> check_struct_pat_fields(pcx, span, fields, class_fields, struct_id, </ins> substitutions, etc); }

Discussion:
This is one of those bugs where an earlier error is leading to poor error reporting later on in the output. So it should not be considered high priority. Nonetheless, it would be nice if we could strive for error messages to be sane when considered in isolation, which this example violates: Transcript: The issue is that the second message claims that does not have a field named , but it clearly does. I could understand this message if it said vec2 does not have a field named .
Change:
<ins> //@ revisions: edition2015 edition2018 edition2021 //@ [edition2015] edition:2015 //@ [edition2018] edition:2018 //@ [edition2021] edition:2021 //@ compile-flags: --extern import_alias_issue_121168_extern //@ aux-build: import-alias-issue-121168-extern.rs extern crate import_alias_issue_121168_extern as nice_crate_name; fn use_foo_from_another_crate_without_importing_it_first() { let _: Foo<i32> = todo!(); //~ ERROR cannot find type `Foo` in this scope } fn main() {} </ins>

Discussion:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc
Change:
// WfScalar, WfParameter, etc } <ins> // Can only infer to `ty::Int(_) | ty::Uint(_)`. ty::Infer(ty::IntVar(_)) => {} // Can only infer to `ty::Float(_)`. ty::Infer(ty::FloatVar(_)) => {} </ins> ty::Slice(subty) => { self.require_sized(subty, traits::SliceOrArrayElem); }

Discussion:
returns if it can't make progress on an inference variable, and the original obligation should be retried later. However, doesn't check that return type and may (incorrectly) return no obligations. On I suggested this: I'm pretty sure now that it would've prevented this bug. <hr/Looking at the users, only uses this function, and only for the user-specified bounds, so it's possible inference variables are impossible to find (unless normalization introduces them, I guess?). It might be fine to just create obligation for the instead of bailing out (see below, this is the same as moving out of ) It's true that can't be found as the first type in the recursive call, but is a , and it uses . (EDIT: Read the code more carefully and the check is , so while it's not an early like I would prefer, it does seem to only trigger on the root type) However, a few other things call and it would be fine for them to create an obligation rather than erroring out, so maybe itself should do that check? cc
changes the return type of to a and discards it using . Might cause us to be slightly more cautious in the future.
I'm working on a fix that makes itself never bail out, so the check is done in , hopefully that will also work nicely for consts. EDIT: opened .
Change:
// FIXME: if/when the output of the test harness can be tested on its own, this test should be // adapted to use that, and that normalize line can go away <del> // compile-flags:--test </del> <ins> // compile-flags:--test --test-args --test-threads=1 </ins> // rustc-env:RUST_BACKTRACE=0 // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // failure-status: 101

Discussion:
This is causing spurious errors in the testsuite. <details<summaryDetails</summary</detailsOriginally posted by in
We should probably just remove/ignore these tests if they're causing spurious failures at a relatively high rate.
Maybe instead of removing them we could just split them into separate files? That way the order doesn't have to be deterministic, but we're still testing the output is correct.
Somehow this started to appear quite often recently, usually on builder.
Change:
fn next_back(&mut self) -> Option<<I as Iterator>::Item> { self.iter.next_back() } } <ins> #[stable] impl<'a, I> ExactSizeIterator for ByRef<'a, I> where I: 'a + ExactSizeIterator {} </ins> /// A trait for iterators over elements which can be added together #[unstable = "needs to be re-evaluated as part of numerics reform"] pub trait AdditiveIterator<A> {

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
// Second, if there is a guard on each arm, make sure it isn't // assigning or borrowing anything mutably. if let Some(ref guard) = arm.guard { <del> if self.tcx.check_for_mutation_in_guard_via_ast_walk() { </del> <ins> if !self.tcx.features().bind_by_move_pattern_guards { </ins> check_for_mutation_in_guard(self, &guard); } }

Discussion:
Current handling of this feature goes through functions and . One or both of these functions should be removed. cc
NLL triage: prioritizing as P-medium.
Change:
} } <ins> /// An item in `extern { ... }` cannot use non-ascii identifier. fn check_foreign_item_ascii_only(&self, ident: Ident) { let symbol_str = ident.as_str(); if !symbol_str.is_ascii() { let n = 83942; self.err_handler() .struct_span_err( ident.span, "items in `extern` blocks cannot use non-ascii identifiers", ) .span_label(self.current_extern_span(), "in this `extern` block") .note(&format!( "This limitation may be lifted in the future; see issue #{} <https://github.com/rust-lang/rust/issues/{}> for more information", n, n, )) .emit(); } } </ins> /// Reject C-varadic type unless the function is foreign, /// or free and `unsafe extern "C"` semantically. fn check_c_varadic_type(&self, fk: FnKind<'a>) {

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:
<ins> error: qualified path without a trait in glob delegation --> $DIR/glob-traitless-qpath.rs:7:5 | LL |     reuse <u8>::*; |     ^^^^^^^^^^^^^^ error: qualified path without a trait in glob delegation --> $DIR/glob-traitless-qpath.rs:8:5 | LL |     reuse <()>::*; |     ^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' 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: [resolverforloweringraw] getting the resolver for lowering -- label +F-fndelegation
^_^
Fixed in
Change:
thread_local!(static USED_HEADER_MAP: RefCell<HashMap<String, uint>> = { RefCell::new(HashMap::new()) }); <del> thread_local!(static TEST_IDX: Cell<uint> = Cell::new(0)); </del> thread_local!(pub static PLAYGROUND_KRATE: RefCell<Option<Option<String>>> = { RefCell::new(None)

Discussion:
For example, the code snippet for with suspicious muffin-related content. This seems to be the snippet for the  function (which is also the first function on the page with example code). All other code snippets on the page lead to the same muffin code. This is on Chrome 39.0.2171.95 (64-bit) on Mac OS X 10.10.1. !
It looks like this is caused by rustdoc rendering all of the examples with the same id. If you look at the playpen js code in rustdoc: you see that it depends on all the same ids being different. However, if you look at the source of the StrExt example you linked, you see they all have "rust-example-rendered-0" as the id. I think the error comes from somewhere in here, but it's not obvious to me how to fix it. I'll look into the issue, but this is my first little bit of work on rust so it may take a second/I'd appreciate insight as to what the problem might be.
nominating for I-muffins
Change:
// ignored; this is set from an env var set by bootstrap.py download_rustc: Option<StringOrBool> = "download-rustc", lto: Option<String> = "lto", <ins> validate_mir_opts: Option<u32> = "validate-mir-opts", </ins> } }

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
<ins> // Reexport of a structure that derefs to a type with lang item impls having doc links in their // comments. The doc link points to an associated item, so we check that traits in scope for that // link are populated. // aux-build:extern-lang-item-impl-dep.rs #![no_std] extern crate extern_lang_item_impl_dep; pub use extern_lang_item_impl_dep::DerefsToF64; </ins>

Discussion:
(Using + ) (Minimized from ) : <details<summary<strongBacktrace</strong</summary<p</p</detailscc
One thing I forgot to do is check that my minimization is exhaustive. After deleting all the from the original crate it still ICEs, so there must be another way that it is triggering this too.
Could this issue be related/duplicate of (and therefore fixed by )? Also, perhaps replace the team label with ?
I assume you meant ? That was included in which I tested with (we have a collection of failing crates in that I am rebuilding as each fix for the fallout from lands).
Fixed in
Change:
values.0.push_normal(path1); values.1.push_normal(path2); <ins> // Avoid printing out default generic parameters that are common to both // types. let len1 = sub_no_defaults_1.len(); let len2 = sub_no_defaults_2.len(); let common_len = cmp::min(len1, len2); let remainder1: Vec<_> = sub1.types().skip(common_len).collect(); let remainder2: Vec<_> = sub2.types().skip(common_len).collect(); let common_default_params = remainder1.iter().rev().zip(remainder2.iter().rev()) .filter(|(a, b)| a == b).count(); let len = sub1.len() - common_default_params; </ins> // Only draw `<...>` if there're lifetime/type arguments. <del> let len = sub1.len(); </del> if len > 0 { values.0.push_normal("<"); values.1.push_normal("<");

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.
Change:
Err(error) => { ecx.tcx.sess.delay_span_bug( ecx.tcx.span, <del> "error during interning should later cause validation failure", </del> <ins> &format!( "error during interning should later cause validation failure: {}", error ), </ins> ); // Some errors shouldn't come up because creating them causes // an allocation, which we should avoid. When that happens,

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. --code from ./src/test/ui/consts/constconstructor/const-construct- <!-- 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. --rustc @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Might be caused by That should have reduced the number of ICEs, not increased it, but who knows.^^

<!-- 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. --core reduced from <!-- 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. --: repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This does not reproduce with though, so it's a very recent regression.
` produces the same error it seems.
Change:
fi fi <ins> script_import="command script import "$RUSTC_SYSROOT/lib/rustlib/etc/lldb_lookup.py"" commands_file="$RUSTC_SYSROOT/lib/rustlib/etc/lldb_commands" </ins> # Call LLDB with the commands added to the argument list <del> exec "$lldb" --source-before-file ./lldb_commands "$@" </del> <ins> exec "$lldb" --one-line-before-file "$script_import" --source-before-file "$commands_file" "$@" </ins>

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. --I tried this code: I expected to see this happen: To be able to use lldb commands as I can if I use lldb directly Instead, this happened: error: file specified in --source (-s) option doesn't exist: 'lldbcommands' <!-- 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. --: The same happens on a macOS machine I saw that is on directory together with shell script, and I also saw that script calls it directly, but I'm not sure how it should behaves in my machine since the is not there (rustup is not installing it) I've asked it on Rust users forum, and also in the discord chat, but no answers, so I'm considering it a bug, feel free to close it if it is something wrong with my installation and, if possible, guide me on where should I look to fix it.
cc who introduced in . I also notice the script references which isn't set anywhere.
The issue happens because expects and its dependencies resides on the current directory. Just to let you know that I got it working doing this: Cloned this repo on : Edit changing the first line to: Then run the following to link the files to the current directory:
Another important highlight, as mentioned, this is a recent change, so 1.45 was working fine and the issue appeared only on 1.46
Change:
let iter = mem::replace(&mut self.iter, (&mut []).iter()); let drop_len = iter.len(); <del> let drop_ptr = iter.as_slice().as_ptr(); // forget iter so there's no aliasing reference drop(iter); </del> let mut vec = self.vec;

Discussion:
MCVE (could be reduced further): Originally found by miri-test-libstd. See for more. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suspect this is a regression from (, cc but I have not yet bisected.
claim
I have debug printing for the slice length to and the test prints that the iterator is zero-length, which means a zero-length slice is created. refers to regarding safety requirements, which in turn states Which I interpret as any aligned, non-null pointer is valid for zero-length slices, which includes recently freed allocations. So this seems to be a false positive caused by miri not taking the slice length into account.
That is not the case, unfortunately. Quoting from I am not happy with this rule, but currently, LLVM does not really let us a choice here ().
Added 1.59.0 milestone since that's my understanding of when the regression occurred.
Removing prioritization label as per label -I-prioritize
Change:
<ins> fn f() -> impl Sized { 2.0E //~^ ERROR expected at least one digit in exponent } fn main() {} </ins>

Discussion:
Found with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsRegression in nightly-2022-09-18 from ( <details<summaryBisect info</summarysearched nightlies: from nightly-2022-09-04 to nightly-2022-11-07 regressed nightly: nightly-2022-09-18 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.4 Host triple: x86_64-apple-darwin </details
For the record, this isn't dependent on return type, which is a separate error. This also ICEs:
This don't ICE: I guess it's because terminated because the error type error.
Yeah, still needs to implement the trait in the -- this ICEs, for example:
I can take a look at this, unless you're already working on this
I think compiler-errors already submitted a PR to fix this, PR linked above, but he did not claim this issue.
Oh thanks, didn't see this.
Change:
// Regression test for issue #5239 fn main() { <del> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary operation + cannot be applied to type `&int` </del> <ins> let x: |int| -> int = |ref x| { x += 1; }; //~ ERROR binary assignment operation += cannot be applied to type `&int` </ins> }

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
<ins> error[E0478]: lifetime bound not satisfied --> $DIR/issue-88595.rs:19:5 | LL |     type B<'b> = impl Clone; |     ^^^^^^^^^^^^^^^^^^^^^^^^ | note: lifetime parameter instantiated with the lifetime `'a` as defined here --> $DIR/issue-88595.rs:18:6 | LL | impl<'a> A<'a> for C { |      ^^ note: but lifetime parameter must outlive the lifetime `'b` as defined here --> $DIR/issue-88595.rs:19:12 | LL |     type B<'b> = impl Clone; |            ^^ error: non-defining opaque type use in defining scope --> $DIR/issue-88595.rs:23:23 | LL |     fn a(&'a self) -> Self::B<'a> {} |                       ^^^^^^^^^^^ | note: lifetime used multiple times --> $DIR/issue-88595.rs:18:6 | LL | impl<'a> A<'a> for C { |      ^^ LL |     type B<'b> = impl Clone; |            ^^ error: could not find defining uses --> $DIR/issue-88595.rs:19:18 | LL |     type B<'b> = impl Clone; |                  ^^^^^^^^^^ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0478`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p(F# highlighting looks reasonably nice) </p</details
modify labels +requires-nightly +F-genericassociatedtypes +F-typealiasimpl_trait
GATs issue triage: not blocking. Works on latest nightly; needs test.
label: +E-needs-test