jiebi/CodeConvo huggingface dataset:
Code change:
use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

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:
use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

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:
use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

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:
use prelude::v1::*; <ins> #[doc(hidden)] pub use self::imp::KeyInner as __KeyInner; </ins> /// Type representing a thread local storage key corresponding to a reference /// to the type parameter `T`. ///

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:
pub fn has_errors(&self) -> bool { self.diagnostic().has_errors() } <ins> pub fn has_errors_or_delayed_span_bugs(&self) -> bool { self.diagnostic().has_errors_or_delayed_span_bugs() } </ins> pub fn abort_if_errors(&self) { self.diagnostic().abort_if_errors(); }

Related discussion:
text: When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly
Code change:
<del> Subproject commit 6b3dbcc81a470e5da84576d63fcfc19e3b1154cd </del> <ins> Subproject commit 221a195b62f4373a8893f4d022e4ce981b09a857 </ins>

Related discussion:
text: <!-- 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. --Minimized from a program was trying to debug. I tried this code: I expected to see this happen: Instead, this happened: I see this on aarch64 and not on x86_64. I don't have access to any other architectures. Output is as expected with . I can also observe this bug on the previous stable (1.56.1), current beta (1.58.0-beta.3) and current nightly ( 2022-01-10). :
Was able to also test Rust 1.53 & 1.55, both perform as expected and show i: 0
Are the numbers printed the same every time or do they vary?
Consistently on the problem arch & compilers
Thanks. The reason I was asking is that, if you're reading invalid memory, the result is usually random. Since this result is consistent, something else is probably going on.
For the sake of convenience, could you please provide the output for this program?
here you go:
It might be a coincidence but, is (4 bytes in 32-bits) and rounded to the . Seems like maybe the bits are being inverted?
~I'm able to reproduce with , but if I emit the IR and then compile it with , I do not see the issue.~ I get different IR if I compile with vs. the entire command from . Only the 2nd has the bug. Edit: It's caused by . Lowering it to removes the problem.
When I use the llc from the rustup toolchain, I see LLVM going wild with clobbers: Note that also gets passed , so we're actually converting some condition flags to float, which makes about zero sense. Weirdly I don't see this when using the llc from my local rust build :/
For this example, the llc distributed by rustup produces (with ): While my own build produces:
Looks like it works if LLVM is compiled with assertions and breaks when compiled without assertions :(
Are you saying that you can reproduce two different results using the same IR? I was seeing the issue with distributed from Homebrew. Not sure if that's compiled with or without assertions.
Code change:
<del> Subproject commit 6b3dbcc81a470e5da84576d63fcfc19e3b1154cd </del> <ins> Subproject commit 221a195b62f4373a8893f4d022e4ce981b09a857 </ins>

Related discussion:
text: I only see the problem with IR generated with and compiling with . This is the line of IR that is causing the issues. It is only present with and removing it fixes the bug: Additionally, it's only a problem if I assign to the spill directly. If I store a constant or use a temporary, the issue goes away.
seems like it may be relevant. Switching to fixes the miscompilation.
Bisect shows this is fixed by on main. Edit: It looks that shortly after that landed and the change was reverted again.
The revert comment suggests that it should be fixed by . Are you able to confirm?
I've filed to check whether we can still get this in 13.0.1, though probably not. In that case I'll cherry-pick into our fork.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
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. fn foo(_: &'static u32) {} fn unpromotable<T>(t: T) -> T { t } fn main() { foo(&unpromotable(5u32)); } //~^^ ERROR borrowed value does not live long enough </ins>

Related discussion:
text: suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.
Code change:
/// Constructs a floating point number by multiplying `x` by 2 raised to the /// power of `exp` #[inline] <del> fn ldexp(x: f32, exp: int) -> f32 { unsafe { cmath::ldexpf(x, exp as c_int) } </del> <ins> fn ldexp(self, exp: isize) -> f32 { unsafe { cmath::ldexpf(self, exp as c_int) } </ins> } /// Breaks the number into a normalized fraction and a base-2 exponent,

Related discussion:
text: has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.
Code change:
# # Check travis config for `gdb --batch` command to print all crash logs <ins> parameters: # When this parameter is set to anything other than an empty string the tests # will only be executed when the commit updates submodules only_on_updated_submodules: '' </ins> steps: # Disable automatic line ending conversion, which is enabled by default on

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
.find_ancestor_inside(value.span) .map(|span| (value.span.with_hi(span.lo()), value.span.with_lo(span.hi()))), ast::ExprKind::Paren(ref expr) => { <del> expr.span.find_ancestor_inside(value.span).map(|expr_span| { </del> <ins> // For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, // the span should contains the attributes, or the suggestion will remove them. let expr_span_with_attrs = if let Some(attr_lo) = expr.attrs.iter().map(|attr| attr.span.lo()).min() { expr.span.with_lo(attr_lo) } else { expr.span }; expr_span_with_attrs.find_ancestor_inside(value.span).map(|expr_span| { </ins> (value.span.with_hi(expr_span.lo()), value.span.with_lo(expr_span.hi())) }) }

Related discussion:
text: <!-- 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: The warning fires on all three lines of , and the suggestions should only suggest removing the parentheses, not the attribute also. Instead, this happened: The fires on the first and last lines of , and the suggestion also removes the . No warning fires on the second line (but this is probably a separate issue, unrelated to attributes; it happens even when the attribute is removed; maybe overrides it or something). <!-- 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. --: Requires use of , otherwise the is not legal in that position (though note that the warning and suggestion is the same on stable, there's just an first). The issue is not specific to closures and , but that was the simplest example of a reasonable attribute-on-expression I thought of. label +A-diagnostics +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Code change:
assert_eq!(id, LOCAL_CRATE); tcx.crate_name }; <del> providers.maybe_unused_trait_import = |tcx, id| tcx.resolutions(()).maybe_unused_trait_imports.contains(&id); </del> <ins> providers.maybe_unused_trait_imports = |tcx, ()| &tcx.resolutions(()).maybe_unused_trait_imports; </ins> providers.maybe_unused_extern_crates = |tcx, ()| &tcx.resolutions(()).maybe_unused_extern_crates[..]; providers.names_imported_by_glob_use = |tcx, id| {

Related discussion:
text: The resolver gathers a list of possibly unused trait imports in . This list is passed to resolver outputs, into the query. This query takes a and returns whether the import is possibly unused. This is used by the post-typeck unused import check in . This query iterates over all the statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused. As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on . Steps: make an both in and , this will ensure a deterministic iteration order; rename query and give it the signature , and adapt the call site; we do not want to access directly, as this would prevent the query system from detecting that the set has not changed; in , inline and replace the loop over by a loop over ; the filter over there can be removed too (or replaced by a debug-assertion): the set may only point to use statements. Extra: investigate why we check for , and the consequences of removing that check; investigate the impact on perf of converting the to a simple when producing from . I am available on Zulip for any question. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still working on this?
Hello yes sorry for the super slow pace. I am still working on it (mostly reading the rustc dev guide so far). Is that alright or is it important to get this done quickly?
no worries, I am a beginner looking for tasks, hence the qn.
Code change:
if !fail { return None; } <del> bug!("unexpected const parent path {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent path {:?}", x ), ); tcx.types.err </ins> } } }

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
<ins> // https://github.com/rust-lang/rust/issues/113462 struct S2<'b>(&'b ()); struct S<'a, const N: S2>(&'a ()); //~^ ERROR missing lifetime specifier [E0106] //~| ERROR `S2<'_>` is forbidden as the type of a const generic parameter 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
searched nightlies: from nightly-2023-02-17 to nightly-2023-02-19 regressed nightly: nightly-2023-02-18 searched commit range: regressed commit: - -cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
| token::CloseDelim(DelimToken::NoDelim) // The pretty printer collapses many semicolons into one. | token::Semi <ins> // We don't preserve leading `|` tokens in patterns, so // we ignore them entirely | token::BinOp(token::BinOpToken::Or) // We don't preserve trailing '+' tokens in trait bounds, // so we ignore them entirely | token::BinOp(token::BinOpToken::Plus) </ins> // The pretty printer can turn `$crate` into `::crate_name` | token::ModSep = token.kind { return false;

Related discussion:
text: The following code: is currently pretty-printed as: If this occurs in a macro invocation, it leads to an instance of
Extra info (but it boils down to what said): Using I get the following log: Rendered diff:
This applies to all trailing separators in theory (except that the separator is leading rather than trailing in this case), but in other cases the difference is fixed up by fuzzy comparison in .