jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> /// If a tool does not pass its tests, don't ship it. /// Right now, we do this only for Miri. fn check_toolstate(&mut self) { // Get the toolstate for this rust revision. let rev = self.rust_git_commit_hash.as_ref().expect("failed to determine rust git hash"); let toolstates = reqwest::get(TOOLSTATE).expect("failed to get toolstates"); let toolstates = BufReader::new(toolstates); let toolstate = toolstates.lines() .find_map(|line| { let line = line.expect("failed to read toolstate lines"); let mut pieces = line.splitn(2, 't'); let commit = pieces.next().expect("malformed toolstate line"); if commit != rev { // Not the right commit. return None; } // Return the 2nd piece, the JSON. Some(pieces.next().expect("malformed toolstate line").to_owned()) }) .expect("failed to find toolstate for rust commit"); let toolstate: HashMap<String, String> = serde_json::from_str(&toolstate).expect("toolstate is malformed JSON"); // Mark some tools as missing based on toolstate. if toolstate.get("miri").map(|s| &*s as &str) != Some("test-pass") { println!("Miri tests are not passing, removing component"); self.miri_version = None; self.miri_git_commit_hash = None; } } /// Hash all files, compute their signatures, and collect the hashes in `self.digests`. </del> fn digest_and_sign(&mut self) { for file in t!(self.input.read_dir()).map(|e| t!(e).path()) { let filename = file.file_name().unwrap().to_str().unwrap();

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:
} } <ins> impl Allocation<()> { /// Add Tag and Extra fields pub fn retag<T, E>( self, mut tagger: impl FnMut(AllocId) -> T, extra: E, ) -> Allocation<T, E> { Allocation { bytes: self.bytes, size: self.size, relocations: Relocations::from_presorted( self.relocations.iter() // The allocations in the relocations (pointers stored *inside* this allocation) // all get the base pointer tag. .map(|&(offset, ((), alloc))| { let tag = tagger(alloc); (offset, (tag, alloc)) }) .collect() ), undef_mask: self.undef_mask, align: self.align, mutability: self.mutability, extra, } } } </ins> /// Raw accessors. Provide access to otherwise private bytes. impl<Tag, Extra> Allocation<Tag, Extra> { pub fn len(&self) -> usize {

Related discussion:
text: 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.
I need to port parts of from miri to rustc and only keep the actual miri-parts in miri. I'll try to get it done by tomorrow night.
check-in from compiler triage: Go go!
Code change:
<ins> #![feature(const_fn_trait_bound)] // Regression test for issue 88434 const _CONST: &[u8] = &f(&[], |_| {}); const fn f<F>(_: &[u8], _: F) -> &[u8] where F: FnMut(&u8), { panic!() //~ ERROR evaluation of constant value failed } 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. --code from glacier <!-- 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 --
This one also crashes beta and stable release channel.
Huh, why was this not detected earlier if it was tracked in glacier as fixed?
If you add a annotation to the trait bound on , then it no longer ICEs. Here's the code: Output: And if you add the two feature attributes the above messages ask you to enable, it still does not ICE, but correctly errors with "evaluation of constant value failed." Based on some debugging which I , I think this ICE has to do with the lifetime in the bound , although I'm not exactly sure how. I am new to the Rust compiler, and I just chose this issue because it seemed like a good first issue to work on, so I will read the (thanks to for sharing this) and try to further debug this.
If you plan to work on this issue, I recommend claiming it so other people know that and don't start working on it too. You can claim the issue by commenting with . More details about how to use rustbot are . You may also want to read the of the guide.
claim
Code change:
use crate::ffi::CStr; use crate::mem; <del> use crate::os::raw::{c_char, c_int, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </del> <ins> use crate::os::raw::{c_char, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </ins> use crate::os::windows::io::{BorrowedHandle, HandleOrInvalid, HandleOrNull}; use crate::ptr; use core::ffi::NonZero_c_ulong; use libc::{c_void, size_t, wchar_t}; <ins> pub use crate::os::raw::c_int; </ins> #[path = "c/errors.rs"] // c.rs is included from two places so we need to specify this mod errors; pub use errors::*;

Related discussion:
text: (and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.
Code change:
use crate::ffi::CStr; use crate::mem; <del> use crate::os::raw::{c_char, c_int, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </del> <ins> use crate::os::raw::{c_char, c_long, c_longlong, c_uint, c_ulong, c_ushort}; </ins> use crate::os::windows::io::{BorrowedHandle, HandleOrInvalid, HandleOrNull}; use crate::ptr; use core::ffi::NonZero_c_ulong; use libc::{c_void, size_t, wchar_t}; <ins> pub use crate::os::raw::c_int; </ins> #[path = "c/errors.rs"] // c.rs is included from two places so we need to specify this mod errors; pub use errors::*;

Related discussion:
text: I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole
Code change:
let md_content = fs::read_to_string(entry.path()).unwrap(); fs::write(&out_dir.join(entry.file_name()), &md_content).unwrap(); } <del> let mut all = String::new(); all.push_str( r###" fn register_all() -> Vec<(&'static str, Option<&'static str>)> { let mut long_codes: Vec<(&'static str, Option<&'static str>)> = Vec::new(); macro_rules! register_diagnostics { ($($ecode:ident: $message:expr,)*) => ( register_diagnostics!{$($ecode:$message,)* ;} ); ($($ecode:ident: $message:expr,)* ; $($code:ident,)*) => ( $( {long_codes.extend([ (stringify!($ecode), Some($message)), ].iter());} )* $( {long_codes.extend([ stringify!($code), ].iter().cloned().map(|s| (s, None)).collect::<Vec<_>>());} )* ) } "###, ); all.push_str(r#"include!(concat!(env!("OUT_DIR"), "/all_error_codes.rs"));"#); all.push_str("nlong_codesn"); all.push_str("}n"); fs::write(&dest, all).unwrap(); </del> }

Related discussion:
text: Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .
Code change:
} } <ins> fn visit_generic_args(&mut self, args: &'a ast::GenericArgs) { // This check needs to happen here because the never type can be returned from a function, // but cannot be used in any other context. If this check was in `visit_fn_ret_ty`, it // include both functions and generics like `impl Fn() -> !`. if let ast::GenericArgs::Parenthesized(generic_args) = args && let ast::FnRetTy::Ty(ref ty) = generic_args.output && matches!(ty.kind, ast::TyKind::Never) { gate!(&self, never_type, ty.span, "the `!` type is experimental"); } visit::walk_generic_args(self, args); } </ins> fn visit_expr(&mut self, e: &'a ast::Expr) { match e.kind { ast::ExprKind::TryBlock(_) => {

Related discussion:
text: I tried this code: I expected to see this happen: “error[E0658]: the type is experimental” Instead, this happened: Successful compilation, as long as I'm using a nightly compiler, but the error when on stable 1.75. This is incorrect because nightly features should always require attributes on nightly (until they're stabilized, which hasn't happened yet for ). <!-- 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. --: label +F-never_type +requires-nightly
searched nightlies: from nightly-2023-11-11 to nightly-2024-02-01 regressed nightly: nightly-2024-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsThen, bisecting Manually verified that reverting (as ) restored the error. cc
Not sure to understand why fixing the visitor implementation introduced this bug. Maybe it highlighted a limitation? Gonna check.
Ok I think I know why: implementation of the not calling the equivalent function. Checking where it is used.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix was already approved in . Waiting for CI to be unlocked.
Code change:
static WAKER: Waker = unsafe { Waker::from_raw(VOID_WAKER) }; <del> static CONTEXT: Context<'static> = Context::from_waker(&WAKER); static WAKER_REF: &'static Waker = CONTEXT.waker(); WAKER_REF.wake_by_ref(); </del> <ins> WAKER.wake_by_ref(); </ins> }

Related discussion:
text: One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation.
Code change:
static WAKER: Waker = unsafe { Waker::from_raw(VOID_WAKER) }; <del> static CONTEXT: Context<'static> = Context::from_waker(&WAKER); static WAKER_REF: &'static Waker = CONTEXT.waker(); WAKER_REF.wake_by_ref(); </del> <ins> WAKER.wake_by_ref(); </ins> }

Related discussion:
text: But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct).
Code change:
static WAKER: Waker = unsafe { Waker::from_raw(VOID_WAKER) }; <del> static CONTEXT: Context<'static> = Context::from_waker(&WAKER); static WAKER_REF: &'static Waker = CONTEXT.waker(); WAKER_REF.wake_by_ref(); </del> <ins> WAKER.wake_by_ref(); </ins> }

Related discussion:
text: Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g.
Code change:
static WAKER: Waker = unsafe { Waker::from_raw(VOID_WAKER) }; <del> static CONTEXT: Context<'static> = Context::from_waker(&WAKER); static WAKER_REF: &'static Waker = CONTEXT.waker(); WAKER_REF.wake_by_ref(); </del> <ins> WAKER.wake_by_ref(); </ins> }

Related discussion:
text: if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .