jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0433]: failed to resolve: `String` is a struct, not a module --> $DIR/unresolved-segments-visibility.rs:8:27 | LL |         pub(in b::string::String::newy) extern crate alloc as e; |                           ^^^^^^ `String` is a struct, not a module error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
} } }, <del> ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) | ty::FnDef(..) => PatKind::Constant { </del> <ins> ty::Bool | ty::Char | ty::Int(_) | ty::Uint(_) => PatKind::Constant { </ins> value: mir::ConstantKind::Ty(ty::Const::new_value(tcx, cv, ty)), }, ty::FnPtr(..) | ty::RawPtr(..) => unreachable!(),

Discussion:
(note: this is very similar to but it does appear to be a different ICE) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +requires-nightly +F-inlineconstpat +requires-incomplete-features

<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +requires-nightly +F-inlineconstpat +requires-incomplete-features
Change:
} impl IntoInner<c::in_addr> for Ipv4Addr { <ins> #[inline] </ins> fn into_inner(self) -> c::in_addr { self.inner }

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: assembly generated should be equivalent to: Instead, this happened: the generated assembly retains calls to Ipv4::octets and Ipv4::from, leaving the assembly poorly optimized I've played with different ways of implementing the safe version, but cannot find anyway get it to optimize further. Good assembly: Bad assembly: and (both include an IPv6 example as well) Adding '-Z mir-opt-level=2' (or higher) does optimize away the call to octets, but not the call to from. I get the same optimization behavior when building a binary, at least on my own platfom (x86-64 Windows MSVC) <!-- 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. --:
Maybe it's just missing s?
I will try to test with adding in the appropriate places in std
This is a trivial method on a concrete type, so yeah, probably just needs . Or you want to turn on LTO. (If it were generic it wouldn't be necessary, but for concrete things the bodies aren't in the meta.)
So I found when a crate exports a function with , it does get optimized where called (though I'm . On the other hand, the same logic inside function will not be inlined: this basic program, for instance, retains assembly calls to octets() and from(): Edit: copy the right "basic program" this time... With on the methods in libstd, the two calls are optimized away. Is this worth a PR to add to libstd? If so, is there anything that shouldn't have in the API? Seems to me like nearly everything would be better inlined, at least for IPv4, but I'm far from an expert.
Feel free to open a PR I guess, your reviewer will decide whether it should be merged or not.
Ping do you want to work on fixing this issue?
Change:
/* General structure */ body { <ins> background-color: white; </ins> margin: 0 auto; padding: 0 15px; font-family: "Source Serif Pro", Georgia, Times, "Times New Roman", serif;

Discussion:
Both the text and the background are black in the steam ingame browser.
The Steam in-game browser is still on Chromium 35 (known security bugs and all) so I think this is more a problem on their end.
We probably just need to set to a light color ourselves. It wouldn't surprise me if Steam has a user agent style that sets the default background color to dark to match the rest of their UI.
Web frontent engineers would use "CSS Reset" scripts:
we are already using
It doesn't really matter that we're using a CSS reset because CSS resets won't do what was originally asked in this issue. If you set body/headline text color, then you have to set the background color too; otherwise you get conflicts with user and user agent stylesheets, like with Steam's browser. CSS resets don't usually set background or text colors on main elements, and they shouldn't.
A screenshot of what this issue is: !
Change:
<ins> error: the `main` function cannot be declared in an `extern` block --> $DIR/extern-main-issue-86110.rs:4:5 | LL |     fn main(); |     ^^^^^^^^^^ error: aborting due to previous error </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. --Not minimal, but possibly helpful, 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
/// This avoids reallocating where possible, but the conditions for that are /// strict, and subject to change, and so shouldn't be relied upon unless the /// `Vec<T>` came from `From<VecDeque<T>>` and hasn't been reallocated. <del> fn from(other: Vec<T>) -> Self { unsafe { let mut other = ManuallyDrop::new(other); let other_buf = other.as_mut_ptr(); let mut buf = RawVec::from_raw_parts(other_buf, other.capacity()); let len = other.len(); // We need to extend the buf if it's not a power of two, too small // or doesn't have at least one free space. // We check if `T` is a ZST in the first condition, // because `usize::MAX` (the capacity returned by `capacity()` for ZST) // is not a power of two and thus it'll always try // to reserve more memory which will panic for ZST (rust-lang/rust#78532) if (!buf.capacity().is_power_of_two() && mem::size_of::<T>() != 0) || (buf.capacity() < (MINIMUM_CAPACITY + 1)) || (buf.capacity() == len) { let cap = cmp::max(buf.capacity() + 1, MINIMUM_CAPACITY + 1).next_power_of_two(); buf.reserve_exact(len, cap - len); </del> <ins> fn from(mut other: Vec<T>) -> Self { let len = other.len(); if mem::size_of::<T>() == 0 { // There's no actual allocation for ZSTs to worry about capacity, // but `VecDeque` can't handle as much length as `Vec`. assert!(len < MAXIMUM_ZST_CAPACITY, "capacity overflow"); } else { // We need to resize if the capacity is not a power of two, too small or // doesn't have at least one free space. We do this while it's still in // the `Vec` so the items will drop on panic. let min_cap = cmp::max(MINIMUM_CAPACITY, len) + 1; let cap = cmp::max(min_cap, other.capacity()).next_power_of_two(); if other.capacity() != cap { other.reserve_exact(cap - len); </ins> } <ins> } unsafe { let (other_buf, len, capacity) = other.into_raw_parts(); let buf = RawVec::from_raw_parts(other_buf, capacity); </ins> VecDeque { tail: 0, head: len, buf } } }

Discussion:
I expected VecDeque constructed from Vec to either work correctly or construction to panic if it is not possible. Instead: Introduced by . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Not sure how severe this is, but figured that it's worth prioritizing.
claim
Assigning and removing as in the prioritization working group.
should fix this -- written before I saw this issue and claim, so I'm sorry if you were still working on it.
Change:
is_main_fn: bool, sigpipe: u8, ) { <del> let main_ret_ty = tcx.fn_sig(rust_main_def_id).output(); </del> <ins> let main_ret_ty = tcx.bound_fn_sig(rust_main_def_id).subst_identity().output(); </ins> // Given that `main()` has no arguments, // then its return type cannot have // late-bound regions, since late-bound

Discussion:
It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.
Change:
panic_unwind = { path = "../panic_unwind", optional = true } panic_abort = { path = "../panic_abort" } core = { path = "../core" } <del> libc = { version = "0.2.77", default-features = false, features = ['rustc-dep-of-std'] } </del> <ins> libc = { version = "0.2.79", default-features = false, features = ['rustc-dep-of-std'] } </ins> compiler_builtins = { version = "0.1.35" } profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" }

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
ConstantHasGenerics, ConstantItemKind, HasGenericParams, PathSource, Rib, RibKind, }; use crate::macros::{sub_namespace_match, MacroRulesScope}; <del> use crate::{AmbiguityError, AmbiguityErrorMisc, AmbiguityKind, Determinacy, Finalize}; </del> <ins> use crate::{errors, AmbiguityError, AmbiguityErrorMisc, AmbiguityKind, Determinacy, Finalize}; </ins> use crate::{Import, ImportKind, LexicalScopeBinding, Module, ModuleKind, ModuleOrUniformRoot}; use crate::{NameBinding, NameBindingKind, ParentScope, PathResult, PrivacyError, Res}; use crate::{ResolutionError, Resolver, Scope, ScopeSet, Segment, ToNameBinding, Weak};

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
use rustc_session::lint::builtin::{AMBIGUOUS_ASSOCIATED_ITEMS, LATE_BOUND_LIFETIME_ARGUMENTS}; use rustc_session::parse::feature_err; use rustc_session::Session; <del> use rustc_span::symbol::{sym, Ident, Symbol}; </del> <ins> use rustc_span::symbol::{kw, sym, Ident, Symbol}; </ins> use rustc_span::{MultiSpan, Span, DUMMY_SP}; use rustc_target::spec::abi; use rustc_trait_selection::traits;

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim
Change:
{ Ok(next_attr) => next_attr, Err(inner_err) => { <del> err.cancel(); </del> inner_err.cancel(); <del> return self.dcx().span_delayed_bug(expr.span, "not a tail expression"); </del> <ins> return err.emit(); </ins> } } && let ast::AttrKind::Normal(next_attr_kind) = next_attr.kind

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim
Change:
use crate::ty::{self, Ty, TyCtxt, TypeFoldable}; use rustc_hir as ast; use rustc_hir::def_id::DefId; <ins> use rustc_span::DUMMY_SP; </ins> use rustc_target::spec::abi; use std::iter;

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
<del> Subproject commit 0c85dbf3df0f545133dca24eccfc9f0f6107c7f8 </del> <ins> Subproject commit e1a0f66373a1a185334a6e3be24e94161e3b4a43 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Miri-side fix at which is blocked on
Also blocked on
triage: P-medium
This was fixes a while ago. But now miri broke again and no new issue was opened? Cc
I was about to post the following here(a few minutes before you commented, RalfJung) when my system , so here it is after a re-run(hence it took only a few seconds instead of 34mins):
The fix is in progress at Building Miri takes 34min for you? oO wow.
ah no, that was the output from building rust.
Blocked on and
Change:
| LL |     core::sync::atomic::AtomicU64::from_mut(&mut 0u64); |                                    ^^^^^^^^ function or associated item not found in `AtomicU64` <ins> | note: if you're trying to build a new `AtomicU64`, consider using `AtomicU64::new` which returns `AtomicU64` --> $SRC_DIR/core/src/sync/atomic.rs:LL:COL = note: this error originates in the macro `atomic_int` (in Nightly builds, run with -Z macro-backtrace for more info) </ins> error: aborting due to previous error

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
<ins> //! This test used to ICE in typeck because of the type/const mismatch, //! even though wfcheck already errored. //! issue: rust-lang/rust#123457 pub struct KeyHolder<const K: u8> {} pub trait ContainsKey<const K: u8> {} pub trait SubsetExcept<P> {} impl<K> ContainsKey<K> for KeyHolder<K> {} //~^ ERROR: type provided when a constant was expected //~| ERROR: type provided when a constant was expected impl<P, T: ContainsKey<0>> SubsetExcept<P> for T {} pub fn remove_key<K, S: SubsetExcept<K>>() -> S { loop {} } fn main() { let map: KeyHolder<0> = remove_key::<_, _>(); //~^ ERROR: the trait bound `KeyHolder<0>: SubsetExcept<_>` is not satisfied } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
#[start] pub async fn start(_: isize, _: *const *const u8) -> isize { <del> //~^ ERROR start is not allowed to be `async` </del> <ins> //~^ ERROR `start` is not allowed to be `async` </ins> 0 }

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .