jiebi/CodeConvo huggingface dataset:
Change:
// check-pass <ins> // edition:2018 </ins> #![warn(semicolon_in_expressions_from_macros)] #[allow(dead_code)]

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
.break_value() } <ins> pub fn try_find_native_dynamic_library( sess: &Session, name: &str, verbatim: bool, ) -> Option<PathBuf> { let formats = if verbatim { vec![("".into(), "".into())] } else { // While the official naming convention for MSVC import libraries // is foo.lib... let os = (sess.target.staticlib_prefix.clone(), sess.target.staticlib_suffix.clone()); // ... Meson follows the libfoo.dll.a convention to // disambiguate .a for static libraries let meson = ("lib".into(), ".dll.a".into()); // and MinGW uses .a altogether let mingw = ("lib".into(), ".a".into()); vec![os, meson, mingw] }; walk_native_lib_search_dirs( sess, LinkSelfContainedComponents::empty(), None, |dir, is_framework| { if !is_framework { for (prefix, suffix) in &formats { let test = dir.join(format!("{prefix}{name}{suffix}")); if test.exists() { return ControlFlow::Break(test); } } } ControlFlow::Continue(()) }, ) .break_value() } </ins> pub fn find_native_static_library(name: &str, verbatim: bool, sess: &Session) -> PathBuf { try_find_native_static_library(sess, name, verbatim) .unwrap_or_else(|| sess.dcx().emit_fatal(errors::MissingNativeLibrary::new(name, verbatim)))

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. --Hi all, I'm coming from to report an inconsistency in how Rust passes library names to Visual Studio's . In the project, which is driven through Meson, I expected all libraries to be found correctly. Instead, I get an error of library not found at linking time. This is caused by the following snippet of code. The above snippet hardcodes the convention when passing import or static libraries' names. However, this is not consistent with , which is already handled correctly in a separate portion of the Rust compiler: The result of the above is that Rust, under MSVC, will happily put together and , but will fail utterly when a is demanded under the present set of circumstances. This is the other half required to completely address the issue in -- I tried working around this by inserting plus setting the correct file name, as shown in , but it returns an error: This is already known and was never addressed: <!-- 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<summaryBacktrace of the big linker error</summary<p</p</details
Any update on this issue?
I see you have done quite a bit of work here, thank you! Is there anything I can do to help move this forward? I can try to build this custom branch and test if it works?
Apologies, I now see the relevant issue is already being worked on!
Change:
let mut region_index = self.region_index; let mut next_name = |this: &Self| { <del> let name = name_by_region_index(region_index, &mut available_names, num_available); debug!(?name); region_index += 1; assert!(!this.used_region_names.contains(&name)); </del> <ins> let mut name; loop { name = name_by_region_index(region_index, &mut available_names, num_available); region_index += 1; if !this.used_region_names.contains(&name) { break; } } </ins> name };

Discussion:
label regression-from-stable-to-nightly regression in , cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-diagnostics
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error[E0277]: can't compare `&[u8; 1]` with `[{integer}; 1]` --> $DIR/issue-113447.rs:24:20 | LL |     let _ = &[0u8] == [0xAA]; |                    ^^ no implementation for `&[u8; 1] == [{integer}; 1]` | = help: the trait `PartialEq<[{integer}; 1]>` is not implemented for `&[u8; 1]` = help: the following other types implement trait `PartialEq<Rhs>`: <[A; N] as PartialEq<[B; N]>> <[A; N] as PartialEq<[B]>> <[A; N] as PartialEq<&[B]>> <[A; N] as PartialEq<&mut [B]>> <[T] as PartialEq<Vec<U, A>>> <[A] as PartialEq<[B]>> <[B] as PartialEq<[A; N]>> <&[u8] as PartialEq<Bytes>> and 4 others help: convert the array to a `&[u8]` slice instead | LL |     let _ = &[0u8] == &[0xAA][..]; |                       +      ++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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 (while debugging): Where is the corresponding type from the crate (and everything else is my types). It has an associated function , which returns a 16-byte slice containing the UUID. Because the right-hand-side of the comparison is not a byte slice but an array, the two expressions can't be compared and I get error E0277, shown below. Of interest is the help message at the end, which has the correct solution, but proposes a fix with invalid syntax. It should suggest placing before . <!-- 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. --: I could not test on nightly, as I got a different compile error, apparently related to procedural macros: <details<summaryError</summary<p</p</details
For the error, see . Could you try to bump your version? Also, could you maybe provide either the full code or a smaller reproduction of the suggestion (if possible), I can't seem to reproduce the suggestion for your pattern on stable.
Thanks for the notice. I just bumped to and retried on nightly: Unfortunately the exact same misleading help message still appears. I managed to reproduce it here: The import or argument is actually necessary to cause the bug. If you remove both, the help message doesn't appear. Perhaps this is related to the crate, which I noticed uses a type alias called (), unrelated to .
Smaller repro but still requires dependency: Am investigating how to get rid of the dependency.
Repro without dependencies:
Change:
~~~ # struct Point { x: f64, y: f64 } <del> let point = &@~Point { x: 10.0, y: 20.0 }; </del> <ins> let point = &~Point { x: 10.0, y: 20.0 }; </ins> println!("{:f}", point.x); ~~~

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
use rustc_span::HashStableContext; use rustc_span::{Loc, Span}; <ins> use std::any::Any; </ins> use std::borrow::Cow; <ins> use std::fmt; </ins> use std::hash::Hash; use std::num::NonZeroUsize; use std::panic; use std::path::Path; <del> use std::{error, fmt}; </del> use termcolor::{Color, ColorSpec};

Discussion:
With beta but nightly does not show backtraces: edits this is with prioritize
can you share your example code, as it doesn't seem that all ICEs are missing backtraces: on the same nightly and beta, and which has a backtrace on both. (if you have the time to do so and a master checkout, it'd be interesting to know whether ThinLTO could be involved like in ; bisection would also be worthwhile)
Hmm interesting, maybe its' something that only happens with :thinking: does not show a backtrace for me ! I also can't force it with or anything :(
This backtrace was removed on purpose in because it's useless. It just points at the place in the error machinery where delayed bugs get flushed, which is either just noise or misleading at worse.
This also affects explicit calls too -- these should be restored in . Regarding s backtraces being useless, see .
Change:
# Summary * [Getting Started](getting-started.md) <del> * [Learn Rust](learn-rust.md) * [Guessing Game](guessing-game.md) * [Dining Philosophers](dining-philosophers.md) * [Rust Inside Other Languages](rust-inside-other-languages.md) </del> <ins> * [Tutorial: Guessing Game](guessing-game.md) </ins> * [Syntax and Semantics](syntax-and-semantics.md) * [Variable Bindings](variable-bindings.md) * [Functions](functions.md)

Discussion:
The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.

I just implemented the code in section 3.3 to compare Ruby to Rust. It appears that rustc optimizes away the inner loop of the thread, because I kept increasing the limit and the completion time remained constant. I introduced a simple if statement in the loop, and then I got expected timings. It might be worth modifying the loop so it's not optimized away for a fairer comparison. Here's what I ended up with:
<sighsorry - I thought I was following the link to submit an issue with the Rust Book, but it appears I've submitted an issue to the Rust language proper :(
the book issues are part of the repo here, yes.
Also, I believe that we either 1) did something to fix this, or 2) there's already an issue open, would you mind checking the nightly book and the other issues?
The example in the book still exhibits the "optimized away" problem. I scanned through all the "A-docs" issues and didn't see anything that matched, but I may have missed something.
Sorry, missed "nightly" above - I'll check that...
Nightly appears to be the same as stable - just a simple loop that rustc is smart enough to collapse.
Roger. Thanks for checking, maybe I'm imagining things.
Change:
msg: &str, followed_by_block: bool) { if let ast::ExprKind::Paren(ref inner) = value.node { <del> let necessary = followed_by_block && if let ast::ExprKind::Ret(_) = inner.node { true } else { parser::contains_exterior_struct_lit(&inner) </del> <ins> let necessary = followed_by_block && match inner.node { ast::ExprKind::Ret(_) | ast::ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), </ins> }; if !necessary { let expr_text = if let Ok(snippet) = cx.sess().source_map()

Discussion:
Rustc 1.30.0-nightly ( 2018-09-29) suggests turning into , which changes the meaning of the program. warning: unnecessary parentheses around condition -- | 5 | if (break { return true }) { | ^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses | = note: #[warn(unused_parens)] on by default
Change:
} #[test] <ins> fn test_utf16_size_hint() { assert_eq!("".encode_utf16().size_hint(), (0, Some(0))); assert_eq!("123".encode_utf16().size_hint(), (1, Some(3))); assert_eq!("1234".encode_utf16().size_hint(), (2, Some(4))); assert_eq!("12345678".encode_utf16().size_hint(), (3, Some(8))); fn hint_vec(src: &str) -> Vec<(usize, Option<usize>)> { let mut it = src.encode_utf16(); let mut result = Vec::new(); result.push(it.size_hint()); while it.next().is_some() { result.push(it.size_hint()) } result } assert_eq!(hint_vec("12"), [(1, Some(2)), (1, Some(1)), (0, Some(0))]); assert_eq!(hint_vec("u{101234}"), [(2, Some(4)), (1, Some(1)), (0, Some(0))]); assert_eq!(hint_vec("u{101234}a"), [(2, Some(5)), (2, Some(2)), (1, Some(1)), (0, Some(0))]); } #[test] </ins> fn starts_with_in_unicode() { assert!(!"├── Cargo.toml".starts_with("# ")); }

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: Instead, this happened: <!-- 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 reason is that the iterator calculates its size hint in terms of the contained iterator size hint, assuming that each character can correspond to either 1 or 2 code units. In the case that the iterator is NOT in the middle of a surrogate pair, this leads to too-low lower bounds and too high upper-bounds. In the case that the iterator IS in the middle of a surrogate pair, the remaining code unit is not taken into account as the iterator has advanced past this point. The actual calculation should be done in terms of the remaining bytes: The lower bound is achieved by assuming the remaining bytes consist of as many 3-byte sequences as possible, optionally followed by a 1 or 2-byte sequence, leading to a lower bound of The upper bound is achieved by assuming the remaining bytes consist of 1-byte sequences, leading to an upper bound of . In the case of the iterator being positioned in the middle of a surrogate pair, both these values should be increased by 1.
, size hints are allowed to be looser than necessary. As the documentation says But if it can be made tighter while still being correct for all values that's fine. Edit: Oh, yeah. This one is actually a bug since the iterator is not exhausted at that point.
Change:
<ins> // compile-flags: -Zmir-opt-level=3 // run-pass #![feature(const_generics)] #![allow(incomplete_features)] fn main() { fn foo<const N: usize>() -> [u8; N] { [0; N] } let _x = foo::<1>(); } </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .
Change:
<ins> // compile-flags: -Zmir-opt-level=3 // run-pass #![feature(const_generics)] #![allow(incomplete_features)] fn main() { fn foo<const N: usize>() -> [u8; N] { [0; N] } let _x = foo::<1>(); } </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
#[derive(Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] /// A specialized set implementation to use enum types. <ins> /// /// It is a logic error for an item to be modified in such a way that the transformation of the /// item to or from a `usize`, as determined by the `CLike` trait, changes while the item is in the /// set. This is normally only possible through `Cell`, `RefCell`, global state, I/O, or unsafe /// code. </ins> pub struct EnumSet<E> { // We must maintain the invariant that no bits are set // for which no variant exists

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
return vec![Annotatable::Item(item)]; } <del> let (sp, attr_sp) = (cx.with_def_site_ctxt(item.span), cx.with_def_site_ctxt(attr_sp)); </del> <ins> let sp = cx.with_def_site_ctxt(item.span); let ret_ty_sp = cx.with_def_site_ctxt(fn_.sig.decl.output.span()); let attr_sp = cx.with_def_site_ctxt(attr_sp); </ins> let test_id = Ident::new(sym::test, attr_sp); // creates test::$name <del> let test_path = |name| cx.path(sp, vec![test_id, Ident::from_str_and_span(name, sp)]); </del> <ins> let test_path = |name| cx.path(ret_ty_sp, vec![test_id, Ident::from_str_and_span(name, sp)]); </ins> // creates test::ShouldPanic::$name let should_panic_path = |name| {

Discussion:
Edit: outstanding work is to change the span from pointing at the function body to point at the return type. adds a test for the case where a unit test returns a value that does not implement . The message currently talks about and has an ugly multi-line span: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending could be possible, but I would advice against doing so to avoid turning that attribute into a bigger monster than it already is.
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about at all as it's plausible to cause people to look in the wrong spot.
CC
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice.
It could get even more confusing when : Rust 1.64
This issue is now (mostly) fixed on nightly by and should be closed I think. The error message is now correct but the span is still “ugly”. I've overlooked this issue and only closed its duplicate, namely .
Actually, let's keep this open only for the span change :)
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct example
Note that this GitHub issue is about the subpar error message given by the compiler which should be fixed and not about potential solutions for user code when facing this message. claim