jiebi/CodeConvo huggingface dataset:
Code change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Related discussion:
text: rustc+cargo 1.40.0 Debian testing packages report the following ICE (which does not go away after a cargo clean): It can be reproduced by trying to build against
Can you try this on nightly?
Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see
triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.
ping icebreakers-cleanup-crew
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rust- cc
Note that when I had a go at building on my Mac laptop, it failed with this message: This is due to in the source crate: So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)
Oops, right, you'll want to just drop that line. It shouldn't have any other effect, its only there due to (at least previously, based on my super-cursory read) libstd calling regular fsync() on OSX, which historically, well, didn't fsync.
I looked at this a bit more. I see the ICE on stable and beta. I do not see the ICE on nightly.
Code change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Related discussion:
text: On nightly, I instead get the following error: <details<summaryClick here to see error diagnostics</summary</details
Possibly associated: Possibly associated: I am not seeing the ICE in: searched nightlies: from nightly-2019-10-01 to nightly-2019-11-01 regressed nightly: nightly-2019-10-08 searched commits: from to regressed commit: source code: built against <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</detailssearched nightlies: from nightly-2019-11-01 to nightly-2020-01-31 fixed nightly: nightly-2019-12-08 searched commits: from to fix commit: source code: built against Possibly here: -
Reduced for in the crate (still depends on ):
This is happening somewhere in item-bodies checking, if I remove the body of with the error goes away.
Ok, I don't have more time to spend on this, I pushed some deletions to
Got it down to two files, but they have to be in different crates: : :
A little smaller: : : <details<summarybacktrace</summary</details
This is a duplicate of , judging by the error message and the fact that I just confirmed as the fixing commit for the reduced example that I created over there. modify labels to -E-needs-mcve.
Code change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Related discussion:
text: Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:
Code change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Related discussion:
text: We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .
Code change:
<ins> pub static TEST_STR: &'static str = "Hello world"; </ins>

Related discussion:
text: rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.
Code change:
} } <del> #[derive(Copy, Clone, PartialEq, Decodable, Encodable, Hash, HashStable_Generic)] </del> <ins> #[derive(Copy, Clone, PartialEq, Eq, Decodable, Encodable, Hash, HashStable_Generic)] </ins> #[rustc_pass_by_value] pub enum Variance { Covariant,     // T<A> <: T<B> iff A <: B -- e.g., function return type

Related discussion:
text: Originally posted by in , see that PR discussion for more detail <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still looking into this? If so, please reassign yourself
claim
Code change:
display: table; } .stab { <del> border-width: 1px; border-style: solid; </del> padding: 3px; margin-bottom: 5px; font-size: 90%;

Related discussion:
text: Right now, the docs produced on the stable and beta channels include unstable items. The docs are already fairly complex and contain a lot of information to sort through, and finding documentation for items that are not usable for the majority of developers working on stable Rust does not help with this. In addition, unstable APIs have very attention-grabbing warnings associated with them, making them much more prominent than the APIs that are actually usable. <img width="1031" alt="Screen shot demonstrating eye-catching unstable warning" src="https://user-"This has been broken out of to provide smaller, actionable items that can be independently discussed and worked on. A review of rustdoc for accessibility, especially for dyslexia and attention disorders, finds that there are a number of visually distracting elements in rustdoc which can draw attention away from the main content. This should be considered along with the other issues mentioned in about the overall effect of a number of distracting elements on the page. This has been previously discussed and closed in and . However, when it was first discussed was very shortly after the Rust 1.0 release, when there was a large amount of API surface which had not been stabilized for the 1.0 release, and what could be done with stable Rust was fairly limited (for example, no stable proc macros so Serde was only usable on nightly Rust). At this point, most people can use stable Rust for most tasks. There is a lot less reason for the average Rust developer to need to switch to nightly to use unstable standard library features. There is also the open issue that the stable docs of unstable items may be out of date; because these items are unstable, they can change in nightly releases, so not only are they a distraction, but they may be misleading for people who actually try to use them. Between the extra information that most people don't need, distracting UI, potential for being out of date, and time since this was last discussed, I think that it is worth reconsidering this decision and hiding unstable items in the stable docs by default. This would require either providing an opt-in setting for seeing them, or make finding the nightly docs easier. An alternative discussed in the comments is to just make them less visually prominent; unstable items are already rendered at lower contrast and at the bottom on module index pages, but within struct or trait documentation they have big bright warning boxes calling attention to them.
Code change:
display: table; } .stab { <del> border-width: 1px; border-style: solid; </del> padding: 3px; margin-bottom: 5px; font-size: 90%;

Related discussion:
text: Making them less visually prominent, such as by reducing their contrast and making the warning just plain unstyled text, perhaps in the same place that stability information goes (though see for discussion on that), would help out a lot.
I would prefer this option. One benefit of showing the unstable APIs is that it invites people to test them, so having an opt-in for the curious would be good.
I would prefer an opt-out to an opt-in, that is, keep what we do today, but provide the ability to hide it if desired.
After spending some more time browsing the docs with an eye out for things that are visually distracting or attention grabbing, another option would be to just use a less attention grabbing way to denote unstable and deprecated items. Right now, they each use an extra, brightly colored box that makes them take up more visual space on the screen than stable items. On module index pages, they are actually made less prominent; they are sorted to the bottom, and made lower contrast with the background. This helps make them less attention catching, rather than more attention catching. But when browsing the methods provided on a struct or trait, they come with the big bright warning boxes that make them stand out more. I think I would still have a slight preference for having them hidden by default and just making the nightly docs easier to discover, such as having a version chooser in the header or sidebar, because of the issue mentioned in about docs of unstable items potentially being out of date. But making them less visually prominent rather than more visually prominent would help a lot.
I agree that the better way to solve this is by (perhaps) reducing the prominence of the "nightly-only" box. I don't think we should hide unstable items in the stable rustdoc generated at If someone is reading code that uses an unstable method, there's a good chance they will go to look it up in the stable docs. It would be a frustrating and confusing experience to not be able to find the method in the docs. It's a much better experience to find the method and be informed it's nightly-only / unstable. We probably don't want to reduce the prominence too much, though. If someone's looking for a method to call, it's pretty important that they notice when it's nightly-only. If they're working on a stable crate, that may mean they're not able to use the method at all.
Candidate PR at
Code change:
<ins> error[E0308]: mismatched types --> $DIR/dont-record-adjustments-when-pointing-at-arg.rs:26:37 | LL |         ns_window.setFrame_display_(0); |                   ----------------- ^ expected `()`, found integer |                   | |                   arguments to this method are incorrect | note: method defined here --> $DIR/dont-record-adjustments-when-pointing-at-arg.rs:5:8 | LL |     fn setFrame_display_(self, display: ()) {} |        ^^^^^^^^^^^^^^^^^       ----------- error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: <!-- 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. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
return None; } <ins> // Handle the special case of -Wall. let wall = matches.opt_strs("W"); if wall.iter().any(|x| *x == "all") { print_wall_help(); return None; } </ins> // Don't handle -W help here, because we might first load plugins. let r = matches.opt_strs("Z"); if r.iter().any(|x| *x == "help") {

Related discussion:
text: It would be nice if turned on all warnings, like how other compilers work.
At least with and , doesn't turn on all the warnings. I don't think turning all on the warnings is ever going to be useful because lots are going to be very domain specific (ones like already are). clang has a fairly useless to turn on all warnings, and to turn on all those included by , and also many more that are considered to be useful. Rust already has all the warnings viewed as useful and not too subjective on by default.
Oh, wow! Thanks for the detailed, thoughtful response. I'll definitely look into each of those options.
(FWIW the warnings are listed in and are almost all on by default)
I think there should be a catch-all lint group, that objectively enables all lints. Whenever programmers decide subjectively to allow lints in some instances, they may then do that on a case-by-case basis. And if an implemented lint simply does not make sense at all then it should be improved/removed. The existing lint group apparently does not include all built-in lint groups, contrary to the output of (): can this issue be reopened?
Reopening. However, I think we shouldn't have any sort of "enable all lints" option; rustc's lints are already all intended to have no or very few false positives (and as such are enabled by default where that makes sense). Could you talk about which specific lints are missing from the default warnings built-in list? I'm not personally aware of any. I'm also somewhat concerned that a or similar option would be confusing to some extent because "all" wouldn't include clippy lints (and probably can't, or at least not easily -- though I don't know the details here).
Issue triage: no longer prints , so that was fixed at some point. (it now prints ) I think it might be useful to have a message explaining why doesn't exist, point the user toward to see all available errors, and suggest adding a for a more thorough lint check. This would help beginners coming from other languages to 1) understand that most useful warnings are turned on by default, 2) tell the user that exists, and 3) show the user that warnings can be controlled from inside the source code, rather than the command line. If there's interest in doing this, I could make a PR.
Code change:
} } } <del> self.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { self.process_path(trait_ref.ref_id, &trait_ref.path); } self.process_generic_params(generics, "", item.id); for impl_item in impl_items { let map = &self.tcx.hir(); self.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } </del> <ins> let map = &self.tcx.hir(); self.nest_tables(item.id, |v| { v.visit_ty(&typ); if let &Some(ref trait_ref) = trait_ref { v.process_path(trait_ref.ref_id, &trait_ref.path); } v.process_generic_params(generics, "", item.id); for impl_item in impl_items { v.process_impl_item(impl_item, map.local_def_id_from_node_id(item.id)); } }); </ins> } fn process_trait(

Related discussion:
text: While compiling rayon:
cc
triage: P-high, assigning to . Removing nomination label.
The fact that this bug was unknown until now strikes me as a sign that we have never attempted to run on the rustc test suite (i.e. compiletest). is this true? Would it be worthwhile to attempt that experiment?
I'm not sure if this is the correct approach, but I just executed the with the following patch applied: and the test suite did crash/ended up all green. It might be a good idea to always run the tests along with save-analysis passed. Should that be optionally enabled? Should we run it, e.g. in the container?
Code change:
base_generics: &ty::Generics<'tcx>) -> ty::Generics<'tcx> { <del> ty_generics(ccx, FnSpace, generics, base_generics) </del> <ins> ty_generics(ccx, FnSpace, generics, base_generics, false) </ins> } fn ty_generic_predicates_for_fn<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>,

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
let thread = thread_info::current_thread(); let name = thread.as_ref().and_then(|t| t.name()).unwrap_or("<unnamed>"); <del> let write = |err: &mut dyn crate::io::Write, backtrace: Option<BacktraceStyle>| { </del> <ins> let write = |err: &mut dyn crate::io::Write| { </ins> let _ = writeln!(err, "thread '{name}' panicked at {location}:n{msg}"); static FIRST_PANIC: AtomicBool = AtomicBool::new(true);

Related discussion:
text: slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.
Code change:
<ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Related discussion:
text: Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Code change:
<ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Related discussion:
text: Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
Code change:
<ins> // Fixed in #66054. // ignore-tidy-trailing-newlines // error-pattern: aborting due to 2 previous errors #[Ѕ </ins>  No newline at end of file

Related discussion:
text: Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens: