jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // The error message here still is pretty confusing. fn main() { let mut result = vec![1]; // The type of `result` is constrained to be `Vec<{integer}>` here. // But the logic we use to find what expression constrains a type // is not sophisticated enough to know this. let mut vector = Vec::new(); vector.sort(); result.push(vector); //~^ ERROR mismatched types // So it thinks that the type of `result` is constrained here. } fn example2() { let mut x = vec![1]; x.push(""); //~^ ERROR mismatched types } </ins>

Related discussion:
text: I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble
Code change:
/// /// assert_eq!(actual, expected); /// ``` <del> #[unstable(feature = "ptr_hash", reason = "newly added", issue = "56286")] </del> <ins> #[stable(feature = "ptr_hash", since = "1.35.0")] </ins> pub fn hash<T: ?Sized, S: hash::Hasher>(hashee: *const T, into: &mut S) { use hash::Hash; hashee.hash(into);

Related discussion:
text: Implemented in as .
Updated from: to: in . Thanks
Seems straightforward enough to me. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Question: We have , should we have as well?
We could, but that’s going quickly into diminishing returns IMO. You can always use something like
Code change:
ENV TARGETS=$TARGETS,aarch64-fuchsia ENV TARGETS=$TARGETS,wasm32-unknown-unknown ENV TARGETS=$TARGETS,wasm32-wasi <del> # FIXME(#61022) - reenable solaris # ENV TARGETS=$TARGETS,sparcv9-sun-solaris # ENV TARGETS=$TARGETS,x86_64-sun-solaris </del> <ins> ENV TARGETS=$TARGETS,sparcv9-sun-solaris ENV TARGETS=$TARGETS,x86_64-sun-solaris </ins> ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32 ENV TARGETS=$TARGETS,x86_64-unknown-cloudabi ENV TARGETS=$TARGETS,x86_64-fortanix-unknown-sgx

Related discussion:
text: Today's nightly (25-05-2019) is missing rust-std for: : https://rust- : https://rust-
This was pointed out in and looks to be fixed in It seems that flew in under the radar of where the actual change to disable these targets happened. want to send a PR to revert the changes so the targets are built again?
Yes, I will do it today.
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
if w > 2 { val = utf8_acc_cont_byte!(val, s[i + 2]); } if w > 3 { val = utf8_acc_cont_byte!(val, s[i + 3]); } <del> return CharRange {ch: unsafe { transmute(val as u32) }, next: i}; </del> <ins> return CharRange {ch: unsafe { transmute(val) }, next: i}; </ins> } return multibyte_char_range_at_reverse(*self, prev);

Related discussion:
text: We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is
Code change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(fn_traits)] fn main() { <fn() as Fn()>::call; //~^ ERROR associated type bindings are not allowed here [E0229] } </ins>

Related discussion:
text: Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:
Code change:
| sym::default_lib_allocator | sym::start | sym::custom_mir, <ins> .. </ins> ] => {} [name, ..] => { match BUILTIN_ATTRIBUTE_MAP.get(name) { // checked below Some(BuiltinAttribute { type_: AttributeType::CrateLevel, .. }) => {} Some(_) => { <del> // FIXME: differentiate between unstable and internal attributes just like we do with features instead // of just accepting `rustc_` attributes by name. That should allow trimming the above list, too. </del> <ins> // FIXME: differentiate between unstable and internal attributes just // like we do with features instead of just accepting `rustc_` // attributes by name. That should allow trimming the above list, too. </ins> if !name.as_str().starts_with("rustc_") { span_bug!( attr.span,

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.
Code change:
repr_packed, repr_simd, repr_transparent, <ins> require, </ins> residual, result, rhs,

Related discussion:
text: I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!
Code change:
<ins> goto: file://|DOC_PATH|/lib2/struct.Foo.html // This test checks that the font weight is correctly applied. assert: ("//*[@class='docblock type-decl']//a[text()='Alias']", {"font-weight": "400"}) assert: ("//*[@class='structfield small-section-header']//a[text()='Alias']", {"font-weight": "400"}) assert: ("#method.a_method > code", {"font-weight": "600"}) assert: ("#associatedtype.X > code", {"font-weight": "600"}) assert: ("#associatedconstant.Y > code", {"font-weight": "600"}) </ins>

Related discussion:
text: It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)
Code change:
} if let Some(ref dox) = i.impl_item.opt_doc_value() { <del> if trait_.is_none() && i.inner_impl().items.is_empty() { </del> <ins> if trait_.is_none() && impl_.items.is_empty() { </ins> w.write_str( "<div class="item-info"> <div class="stab empty-impl">This impl block contains no items.</div>

Related discussion:
text: <p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.
Code change:
<ins> // Regression test for #121534 // Tests that no ICE occurs in KnownPanicsLint when it // evaluates an operation whose operands have different // layout types even though they have the same type. // This situation can be contrived through the use of // unions as in this test //@ build-pass union Union { u32_field: u32, i32_field: i32, } pub fn main() { let u32_variant = Union { u32_field: 2 }; let i32_variant = Union { i32_field: 3 }; let a = unsafe { u32_variant.u32_field }; let b = unsafe { i32_variant.u32_field }; let _diff = a - b; } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)', 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Const prop We need to make it not do union field accesses
Reduced a bit further:
claim
Code change:
// Multibyte case is a fn to allow char_range_at to inline cleanly fn multibyte_char_range_at(s: &str, i: uint) -> CharRange { <del> let mut val = s[i] as uint; </del> <ins> let mut val = s[i] as u32; </ins> let w = UTF8_CHAR_WIDTH[val] as uint; assert!((w != 0));

Related discussion:
text: We need some way to interpret a as UTF-8, using the replacement character for invalid sequences instead of conditions. This would ideally be provided in the form of an .
Could we remove the current condition API in favour of this? It doesn't really seem to offer anything but failing, and we already have an API returning an .
I would be quite pleased if we could do that. Using the condition is rather awkward, and I would rather just have replacement chars myself.
This is a duplicate of , no?
And also the e-mail thread here I think is relevant:
This is an implementation of a mostly complete → UTF-8 decoder
It's only a duplicate if the intended resolution of is to use the replacement char instead of conditions, but it's unclear from the discussion if that's the plan.
I guess my thinking was that a maximally expressive condition-based solution would let one express a replacement char approach using conditions. But I don't actually favor doing that at this point. Or at least, I don't favor making that the only way to accomplish this, since I suspect a more specialized approach will be much nicer to use (both in terms of programmer convenience and in terms of efficiency). So okay, this is not a duplicate of .
Rust needs to support both fatal and replacement error handling modes, it should follow the WHATWG spec simonsapin has said (edit by is WHATWG spec.)
the fatal mode is already handled by the API
well, the current functions in str don't handle decoding buffers in chunks like the proposed encodings API. But yes, it does handle one-off decoding with 'fatal' error handling.
I think we need to improve/extend our API along the lines suggested here for 1.0. Nominating for P-backcompat-lang. (Arguably we could avoid the backwards compatibility hazard by offering a fail-only method for 1.0 and then adding an alternative entry point that provides the more flexible API supporting replacement characters in post 1.0. But I think this case is important enough that we should try to get the primary API method to provide both choices up front. That, or put dynamic fluid support in for representing the state of that choice.)
I submitted a PR for this last night, although I forgot there was an open issue too so I didn't link them. The PR is
Code change:
let crate_types = if options.proc_macro_crate { vec![config::CrateType::ProcMacro] } else { <del> vec![config::CrateType::Dylib] </del> <ins> vec![config::CrateType::Rlib] </ins> }; let sessopts = config::Options {

Related discussion:
text: I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.