jiebi/CodeConvo huggingface dataset:
Code change:
sysinfo = { version = "0.26.0", optional = true } clap = { version = "4.2.4", default-features = false, features = ["std", "usage", "help", "derive", "error-context"] } clap_complete = "4.2.2" <ins> semver = "1.0.17" </ins> # Solaris doesn't support flock() and thus fd-lock is not option now [target.'cfg(not(target_os = "solaris"))'.dependencies]

Related discussion:
text: I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.
Code change:
sysinfo = { version = "0.26.0", optional = true } clap = { version = "4.2.4", default-features = false, features = ["std", "usage", "help", "derive", "error-context"] } clap_complete = "4.2.2" <ins> semver = "1.0.17" </ins> # Solaris doesn't support flock() and thus fd-lock is not option now [target.'cfg(not(target_os = "solaris"))'.dependencies]

Related discussion:
text: building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.
Code change:
target_os = "openbsd", target_arch = "aarch64", no_elf_tls)))] <ins> #[doc(hidden)] </ins> mod imp { use std::cell::Cell;

Related discussion:
text: There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?
Code change:
target_os = "openbsd", target_arch = "aarch64", no_elf_tls)))] <ins> #[doc(hidden)] </ins> mod imp { use std::cell::Cell;

Related discussion:
text: Then the actual borrow of a static is an implementation detail and happens on the thread where the key is used, not where it was itself borrowed.
"I believe the only way #[threadlocal] statics can be safe is by requiring the absence of ." This is wrong, I think. For example, one might use thread local data for intrusive linked lists of hazard pointers. They would be thread local but might still be (one can guarantee existence with scoped threads or in certain circumstances where threads are bound to cores). That said you can obviously come up with other representations. In any case, I've mostly come around to believing that we need a separate lifetime (not just for this, but for things like ensuring that can't catch an error in a thread that changes thread local data, violating exception safety).
Based on what wrote, it seems like the TLS interface requires a that only allows non- data and is still accessible like one. One idea I had of how to enable this in todays Rust is to make generate a unit like struct instead of a . That struct would be and have a impl: According to this could also help with , but I'm not familiar enough with the TLS API in general to really reason about this.
I was expecting the impl to target an intermediary type, not the contents themselves. and have their own APIs to deal with. You would still be about to use the TLS API provided by libstd with thread-safe data, it's just the low-level which would have the requirement. Ideas of thread-local lifetimes predate the removal of from , and I'm not sure how relevant they are anymore. I'm also conflating thread-safe data access and thread lifetime... but how long does a thread live? What would unify with? Actually, there's an... easy solution for this. Somehow we were blinded by language semantics, but their details are fluid. It is trivial to make borrows of behave like borrows of an arbitrary rvalue, allowing the resulting reference to be passed down, but not returned. That would ensure that the the thread is just as alive for such borrows as it is for stack ones. would still require a like has, because it may not be when native TLS is supported. But both their APIs are compatible with such a change.
Wouldn't that limit the usability of thread locals in some cases, though?
Code change:
target_os = "openbsd", target_arch = "aarch64", no_elf_tls)))] <ins> #[doc(hidden)] </ins> mod imp { use std::cell::Cell;

Related discussion:
text: e.g., wouldn't that make it difficult to have a thread local point to another thread local? Maybe I just have to think about it. (BTW, I'm aware we're just talking about the low-level API :)).
in a , borrows are , I didn't even think of that. First off, a global static shouldn't be allowed to borrow a static. And in general, having borrows in a is going to be difficult to support, except for non- data, because they would be right now. We could disallow borrows or we could give some kind of scope to those borrows. Which makes me think, as a compromise between a lifetime and , there could be a pseudo-(rvalue)-scope. Combined with the ability to leave out in globals' type (or not having a type at all), the scope should bubble up into users of those statics. They would behave as if they were borrowed before everything else in the function where they're used, but still not (and they can't be returned from functions).
There's a few intertwined issues here at play, so I just want to quickly summarize the way I see things: This does not affect as it which has an , which while sound should be fixed, allowing removal of the block for . A borrow of a static should not yield something with the lifetime, as that is clearly not sound. I'm not sure I follow why we might require the types in a are not , I haven't quite followed that. Due the cross-platform requirements of std, however, I believe the best solution here is to use the same strategy as with an indirect accessor to ensure the semantics are the same across platforms that have and those that don't (where a normal is used).
triage: P-medium This is an unstable API so it's not super-high priority to fix, but we should defnitely fix!
requiring that a is not is an easy way to ensure that a borrow of it, while , cannot escape the current thread. I've changed my mind and prefer an rvalue borrow semantic for , but it still is the case that and use non- statics (ignoring the workarounds for ). If was supported everywhere, having rvalue borrow semantics wouldn't hurt the std TLS API (aside from stability issues with ), as the access patterns are already through anonymous lifetimes (references passed to closures).
Code change:
target_os = "openbsd", target_arch = "aarch64", no_elf_tls)))] <ins> #[doc(hidden)] </ins> mod imp { use std::cell::Cell;

Related discussion:
text: Maybe a combined strategy, where borrows of statics are iff the data is not (and rvalue-like otherwise), might work better and would require fewer changes to the std TLS implementation.
Right, but returning a borrow with a lifetime for a global is unsafe for other reasons (the lifetime of the thread is not ).
how can it be abused without sending it to a different thread?
The actual values themselves do not have a lifetime, so it can be a source of unsafety to advertise otherwise. For example you could stick a into a TLS value with a destructor, but when the destructor runs that pointer could be invalid.
Code change:
None } }) <del> .filter(|feature| { RUSTC_SPECIAL_FEATURES.contains(feature) || features.contains(&Symbol::intern(feature)) }) </del> <ins> .filter(|feature| features.contains(&Symbol::intern(feature))) </ins> .map(|feature| Symbol::intern(feature)) .collect() }

Related discussion:
text: introduced what I think is a logic error: is now always on s390x targets, even if the feature gate is not set. I verified this with Miri, which shares the logic with rustc so it should be a correct test. This should print when built without (as the feature seems off-by-default), but prints instead: Cc
I believe this is intended. is an always-available code-generation option in LLVM disguised as a target feature. Also, enabling for a single function is useless due to how IBM Z's mechanism works.
By "always available" you mean that there is no difference between and ? But then why would one set this feature?
There are differences between the code generated with or without attribute. Still, unlike other processors, this is a platform-specific (potential) unwinding mechanism that does not require additional processor features when you don't have DWARF information or don't want to use it (profilers on IBM Z systems may use it).
The point of is to reflect whether the feature is enabled. It doesn't matter whether it could be enabled or anything like that. For example, is false unless you are building with . It's not about whether static builds are "available" (that's not even a meaningful question), it's about the flags used to build this code. Maybe you are confusing with . Those are not the same thing. If this is not actually a target feature, then it is not clear that we want this to be a target feature in Rust. Though I guess is (unfortunately) precedent here. What happens when I mix code built with and without ? Does anything go wrong?
No, it just means you won't be able to perform unwinding actions based purely on backchain information.
If you want to know how Clang passes attribute in this situation, you can take a look at this Godbolt playground: In this example, is specified (see ), so the compiler needs to generate backchain-enabled code.
Okay, thanks. I don't fully understand the consequences of that -- if this makes Rust panic catching go wrong, that still seems bad -- but :shrug: whatever. The point of the issue is that the behavior of is wrong. Are you still arguing against that or have my examples above been convincing?
Code change:
None } }) <del> .filter(|feature| { RUSTC_SPECIAL_FEATURES.contains(feature) || features.contains(&Symbol::intern(feature)) }) </del> <ins> .filter(|feature| features.contains(&Symbol::intern(feature))) </ins> .map(|feature| Symbol::intern(feature)) .collect() }

Related discussion:
text: It is currently inconsistent with how behaves, which is a similar kind of "target feature" that's really more like a boolean codegen toggle.
Hmm, I don't know what we should do here, if we need to fix this issue, how should we avoid passing the to in the current framework?
The logic that decides what to pass to LLVM and the logic that decides what is set in are completely independent. (That's fairly recent and might have happened after you implemented this feature.) I think all that needs to be done is change this to simply The feature will have been to in . But better add a test for this to be sure.
Yes, I believe the change was done after I . I will try to implement this change then.
Code change:
c::BCRYPT_USE_SYSTEM_PREFERRED_RNG, ) }; <del> if ret == 0 { Ok(v) } else { Err(io::Error::last_os_error()) } </del> <ins> if ret != 0 { fallback_rng() } else { v } </ins> } /// Generate random numbers using the fallback RNG function (RtlGenRandom) #[cfg(not(target_vendor = "uwp"))] <del> fn fallback_rng() -> Result<(u64, u64), io::Error> { </del> <ins> #[inline(never)] fn fallback_rng() -> (u64, u64) { </ins> let mut v = (0, 0); let ret = unsafe { c::RtlGenRandom(&mut v as *mut _ as *mut u8, mem::size_of_val(&v) as c::ULONG) }; <del> if ret != 0 { Ok(v) } else { Err(io::Error::last_os_error()) } </del> <ins> if ret != 0 { v } else { panic!("fallback RNG broken: {}", io::Error::last_os_error()) } </ins> } /// We can't use RtlGenRandom with UWP, so there is no fallback #[cfg(target_vendor = "uwp")] <del> fn fallback_rng() -> Result<(u64, u64), io::Error> { Err(io::const_io_error!(io::ErrorKind::Unsupported, "RtlGenRandom() not supported on UWP")) </del> <ins> #[inline(never)] fn fallback_rng() -> (u64, u64) { panic!("fallback RNG broken: RtlGenRandom() not supported on UWP"); </ins> }

Related discussion:
text: I tried this code: I expected it to work on Windows 7 the same as it works on other platforms. Instead, this happened: the code get stuck in the initialization of logging, we acquired same-ish stack from multiple people using Windows 7 It was always calling ! On Windows 10 as under Wine the application starts normally My rust code produces DLL that is loaded by C++ application from 10 years ago Latest working version: Earliest version that gets stuck:
seems possibly relevant, but since this is just hanging, I’m not sure we can blame it all on snake oil this time. Though maybe? Wouldn’t be the first time it breaks the system in incomprehensible ways. First and foremost – could you minimize the reproducer? Both from the perspective of the Rust code (sounds like simply calling from should suffice?) and the OS setup (does this occur on a fresh OS install? If not, what modifications are necessary for the reduced reproducer to start hanging)
The nightly that it first started failing under is the first nightly after was merged, which just happens to be directly related to ? That's really whack given that the stack trace above shows the hang taking place just before any of the changes that PR introduced are invoked.
I personally do not have Windows 7, and would prefer not not bother players with more testing unless really necessary. But I can confirm that at least one of the systems was clean Windows 7 Home Premium from . And calling directly seems pretty complicated :( It requires calling which still requires knowing which algorithm to chose, and what flags to use :( I also see this in the documentation: and this in the code: , but unfortunately I can not say how relevant that it.
It's unlikely to be a problem with itself as that works in the earlier version. Is this code being used in ? In any case, I think the fix here is to simplify the rng code so it's as close to the old version as possible.
Yes logging is initialized in DllMain, I will soon post a very small example
So it is related to it being library.
Code change:
c::BCRYPT_USE_SYSTEM_PREFERRED_RNG, ) }; <del> if ret == 0 { Ok(v) } else { Err(io::Error::last_os_error()) } </del> <ins> if ret != 0 { fallback_rng() } else { v } </ins> } /// Generate random numbers using the fallback RNG function (RtlGenRandom) #[cfg(not(target_vendor = "uwp"))] <del> fn fallback_rng() -> Result<(u64, u64), io::Error> { </del> <ins> #[inline(never)] fn fallback_rng() -> (u64, u64) { </ins> let mut v = (0, 0); let ret = unsafe { c::RtlGenRandom(&mut v as *mut _ as *mut u8, mem::size_of_val(&v) as c::ULONG) }; <del> if ret != 0 { Ok(v) } else { Err(io::Error::last_os_error()) } </del> <ins> if ret != 0 { v } else { panic!("fallback RNG broken: {}", io::Error::last_os_error()) } </ins> } /// We can't use RtlGenRandom with UWP, so there is no fallback #[cfg(target_vendor = "uwp")] <del> fn fallback_rng() -> Result<(u64, u64), io::Error> { Err(io::const_io_error!(io::ErrorKind::Unsupported, "RtlGenRandom() not supported on UWP")) </del> <ins> #[inline(never)] fn fallback_rng() -> (u64, u64) { panic!("fallback RNG broken: RtlGenRandom() not supported on UWP"); </ins> }

Related discussion:
text: I tried Application Verifier, because I was wondering what it does. My code is in the dll, and it seems to not work for only dll, so I needed to enable the tests for the exe directly. did not catch anything. But what is bit more funny is that enabling causes the application to fail so early that none of my code is executed... (at least if I set it up correctly and understand what it is doing)
Code change:
# libcurl, instead it should compile its own. ENV LIBCURL_NO_PKG_CONFIG 1 <ins> # There was a bad interaction between "old" 32-bit binaries on current 64-bit # kernels with selinux enabled, where ASLR mmap would sometimes choose a low # address and then block it for being below `vm.mmap_min_addr` -> `EACCES`. # This is probably a kernel bug, but setting `ulimit -Hs` works around it. # See also `src/ci/run.sh` where this takes effect. ENV SET_HARD_RLIMIT_STACK 1 </ins> ENV DIST_REQUIRE_ALL_TOOLS 1

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.