jiebi/CodeConvo huggingface dataset:
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. #![crate_name = "foo"] #![unstable(feature = "humans", reason = "who ever let humans program computers, we're apparently really bad at it", issue = "0")] #![feature(rustc_const_unstable, const_fn, foo, foo2)] #![feature(min_const_unsafe_fn)] #![feature(staged_api)] // @has 'foo/fn.foo.html' '//pre' 'pub unsafe fn foo() -> u32' #[stable(feature = "rust1", since = "1.0.0")] #[rustc_const_unstable(feature="foo")] pub const unsafe fn foo() -> u32 { 42 } // @has 'foo/fn.foo2.html' '//pre' 'pub fn foo2() -> u32' #[unstable(feature = "humans", issue="0")] pub const fn foo2() -> u32 { 42 } // @has 'foo/fn.bar2.html' '//pre' 'pub const fn bar2() -> u32' #[stable(feature = "rust1", since = "1.0.0")] pub const fn bar2() -> u32 { 42 } // @has 'foo/fn.foo2_gated.html' '//pre' 'pub unsafe fn foo2_gated() -> u32' #[unstable(feature = "foo2", issue="0")] pub const unsafe fn foo2_gated() -> u32 { 42 } // @has 'foo/fn.bar2_gated.html' '//pre' 'pub const unsafe fn bar2_gated() -> u32' #[stable(feature = "rust1", since = "1.0.0")] pub const unsafe fn bar2_gated() -> u32 { 42 } // @has 'foo/fn.bar_not_gated.html' '//pre' 'pub unsafe fn bar_not_gated() -> u32' pub const unsafe fn bar_not_gated() -> u32 { 42 } </ins>

Related discussion:
text: Regression from 1.26.0 to 1.27.0 and later. See for example See also and
Code change:
// Consistency checks, analogous to `finalize_macro_resolutions`. if let Some(initial_module) = import.imported_module.get() { if !ModuleOrUniformRoot::same_def(module, initial_module) && no_ambiguity { <del> span_bug!(import.span, "inconsistent resolution for an import"); </del> <ins> let msg = "inconsistent resolution for an import"; self.r.session.span_err(import.span, msg); </ins> } } else { if self.r.privacy_errors.is_empty() {

Related discussion:
text: I tried this code: I expected to see this happen: Compilation error. This shadows one (glob-imported) with another . As far as I know, this should be forbidden. Instead, this happened: this code successfully compiled. : c.c. c.c.
Shadowing a glob import with a specific item is allowed and will unambiguously resolve to the specific one. This is also how the prelude works. The following compiles fine as well: .
To clarify, the problem is not shadowing, but time travel. We shadow identifier which have been already used to resolve another import, so we end up with meaning two things at the same time in the same scope.
This is a change from Rust 1.44, in Rust 1.43 this is an ICE "inconsistent resolution for an import". Possibly a consequence of
I'm not sure this is a bug. When resolving we are looking at all names in scope except for the names introduced by itself. Otherwise we'd have cycles even in trivial cases like where is a name from extern prelude. If you take this detail into consideration, then all paths seem to be resolved correctly.
cc (somewhat related)
I think, the difference with is that doesn't replace one resolution with another. We already have a name in the scope that is resolved to a particular extern crate. In my example, uses name from the scope, and then rebinds this name to another item. I can complicate my example a bit. What this program prints, "111" or "222"? It'd say, it depends on imports resolution order, but looks like it always prints "111".
It'd say, it depends on imports resolution order The intent for the resolution results is to never depend on internal resolution order. (cc , order-dependence can probably happen in practice due to the current not very principled implementation, but hopefully still can be eliminated in backward-compatible-in-practice way by rewriting the main resolution/expansion loop more carefully.) but looks like it always prints "111" That's what I'd expect. resolves to in resolves to (because non-globs shadow globs) first in resolves to (which the only in scope after excluding itself)
I'd still be ok with replacing the former ICE with an error though, since that's a more conservative choice.
Code change:
// Consistency checks, analogous to `finalize_macro_resolutions`. if let Some(initial_module) = import.imported_module.get() { if !ModuleOrUniformRoot::same_def(module, initial_module) && no_ambiguity { <del> span_bug!(import.span, "inconsistent resolution for an import"); </del> <ins> let msg = "inconsistent resolution for an import"; self.r.session.span_err(import.span, msg); </ins> } } else { if self.r.privacy_errors.is_empty() {

Related discussion:
text: Actually enabling the property "name resolve to the same thing whether some items were excluded during its resolution to avoid cycles or not" may be useful for using something like "inference variables" for unresolved imports and making import resolution more like unification in type inference. That's an idea I had for quite some, but I hadn't realized that merging went against it.
Sigh, the issue already affects three stable releases - from 1.44 to 1.46. I'll try to prioritize it.
Addressed in
Assigning so this isn't lost. See the .
The fix caused some regressions -
The code in the issue produce no errors using Rust 1.67.1. Should we re-open the issue or is it not considered a bug now?
The fix was reverted due to breakage () and the current behavior is considered by design since then.
(Also it's not exactly a time travel - )
Code change:
source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "mime 0.3.13 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "unicase 1.4.2 (registry+https://github.com/rust-lang/crates.io-index)", ]

Related discussion:
text: I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.
Code change:
source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "mime 0.3.13 (registry+https://github.com/rust-lang/crates.io-index)", <del> "phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "phf 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", "phf_codegen 0.7.24 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "unicase 1.4.2 (registry+https://github.com/rust-lang/crates.io-index)", ]

Related discussion:
text: That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps
Code change:
#[unstable(feature = "scoped_tls", reason = "scoped TLS has yet to have wide enough use to fully  consider stabilizing its interface")] <del> pub use self::scoped::ScopedKey; </del> <ins> pub use self::scoped_tls::ScopedKey; </ins> #[doc(hidden)] pub use self::local::__impl as __local; <del> #[doc(hidden)] pub use self::scoped::__impl as __scoped; </del> <ins> #[doc(hidden)] pub use self::scoped_tls::__impl as __scoped; </ins> //////////////////////////////////////////////////////////////////////////////// // Builder

Related discussion:
text: I have no idea what's causing this, but on the current nightly, this fails: with "use of unstable library feature 'threadlocalinternals'." Enabling the feature works, but this should be a stable function. Interestingly, tweaking the works: I wonder if it's because there is a (private) sub-module called which has a module-wide marker. Version info:
This change was introduced just recently: I reproduced the problem without using anything thread-related: Commands: Output: If I remove the attribute from the module, the code gives me the error. I mark as stable, then the code compiles. If I instead remove the function, I get the bar error. cc
With merged, is this fixed?
The exact issue at hand has been resolved, but the underlying issue remains. Specifically a module and free-function of the same name but different stability level will cause problems.
Also hit by this; still affecting the nightly for osx right now, but hopefully the next build will include the fix.
Stability is an internal detail. This is unlikely to impact out-of-tree code.
Code change:
self.register_predicates(autoderef.into_obligations()); // Write out the final adjustments. <del> self.apply_adjustments(self.self_expr, adjustments); </del> <ins> if !self.skip_record_for_diagnostics { self.apply_adjustments(self.self_expr, adjustments); } </ins> target }

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:
<ins> // check-pass // effects ice https://github.com/rust-lang/rust/issues/113375 index out of bounds #![allow(incomplete_features, unused)] #![feature(effects, adt_const_params)] struct Bar<T>(T); impl<T> Bar<T> { const fn value() -> usize { 42 } } struct Foo<const N: [u8; Bar::<u32>::value()]>; pub fn main() {} </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. --<!-- 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
cc
Now fixed by errors, see rust-lang/glacier. However, the new error looks unrelated to and it might just be the case that it masks a still existing bug, not sure.
Fixed on the latest nightly, marking as E-needs-test (or, feel free to close if we have a sufficient regression test) labels: +E-needs-test
Code change:
"you may want to use a bool value instead", format!("{}", item_typo), )) <ins> // FIXME(vicnenzopalazzo): make the check smarter, // and maybe expand with levenshtein distance checks } else if item_str.as_str() == "printf" { Some(( item_span, "you may have meant to use the `print` macro", "print!".to_owned(), )) </ins> } else { suggestion };

Related discussion:
text: We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor
Code change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn lock(&self) -> StderrLock<'_> { <ins> self.lock_any() } // Locks this handle with any lifetime. This depends on the // implementation detail that the underlying `ReentrantMutex` is // static. fn lock_any<'a>(&self) -> StderrLock<'a> { </ins> StderrLock { inner: self.inner.lock() } } <ins> /// Locks and consumes this handle to the standard error stream, /// returning a writable guard. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Write`] trait for writing /// data. /// /// # Examples /// /// ``` /// #![feature(stdio_locked)] /// use std::io::{self, Write}; /// /// fn foo() -> io::Result<()> { ///     let stderr = io::stderr(); ///     let mut handle = stderr.into_locked(); /// ///     handle.write_all(b"hello world")?; /// ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn into_locked(self) -> StderrLock<'static> { self.lock_any() } </ins> } #[stable(feature = "std_debug", since = "1.16.0")]

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
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. #[allow(unreachable_code)] fn main() { loop { break while continue { //~ ERROR E0590 } } } </ins>

Related discussion:
text: Input: Output: This is on commit .
I've edited that code just recently so would want to work on this
Made PR to fix this
Thanks for fixing this :-) I also reported a couple of other looping-related bugs in in case you also want to have a look at those.
wow those are quite nice bugs :p. Will have a look.
Code change:
self.lldb_git_commit_hash = self.git_commit_hash("lldb", "x86_64-unknown-linux-gnu"); self.miri_git_commit_hash = self.git_commit_hash("miri", "x86_64-unknown-linux-gnu"); <del> self.check_toolstate(); </del> self.digest_and_sign(); let manifest = self.build_manifest(); self.write_channel_files(&self.rust_release, &manifest);

Related discussion:
text: Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.
Code change:
cd .. rm -rf gcc-build rm -rf gcc-$GCC <del> yum erase -y gcc gcc-c++ binutils </del>

Related discussion:
text: The docs currently claim that the minimum Linux kernel version for is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017. Should we continue to support RHEL 5 for , or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? . Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in . Example: .
Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and back when RHEL 5 still had maintenance support. It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks). Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: and ). It has 5 major steps: Full Support Normal support of the OS Maintenance Support 1 Bug/Security fixes Limited hardware refresh Maintenance Support 2 Bug/Security fixes The end of this phase is considered "Product retirement" Extended Life Cycle Support (ELS) Additional paid product from Red Hat Gives updates for a longer period of time No additional releases/images Extended Life Phase (ELP) No more updates Limited Technical Support End date not given by Red Hat Current status of RHEL versions: RHEL 4 Not supported by Rust Currently in ELP (no end date specified) ELS ended March 31, 2017 RHEL 5 Supported by Rust Currently in ELS Maintenance Support ended March 31, 2017 ELS ends November 30, 2020 RHEL 6 Supported by Rust Currently in Maintenance Support 2 Maintenance Support ends November 30, 2020
cc which I think they could be related.