jiebi/CodeConvo huggingface dataset:
Code change:
target_os = "openbsd", target_arch = "aarch64", no_elf_tls))] <ins> #[doc(hidden)] </ins> mod imp { use prelude::v1::*;

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 prelude::v1::*;

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 prelude::v1::*;

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 prelude::v1::*;

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:
<ins> // Copyright 2014 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 main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<ins> // Copyright 2014 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 main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<ins> // Copyright 2014 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 main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<ins> // Copyright 2014 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 main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
// handled below clean::ModuleItem(..) => {} <del> // impls/tymethods have no control over privacy clean::ImplItem(..) | clean::TyMethodItem(..) => {} </del> <ins> // trait impls for private items should be stripped clean::ImplItem(clean::Impl{ for_: clean::ResolvedPath{ id: ref for_id, .. }, .. }) => { if !self.exported_items.contains(for_id) { return None; } } clean::ImplItem(..) => {} // tymethods have no control over privacy clean::TyMethodItem(..) => {} </ins> } let fastreturn = match i.inner {

Related discussion:
text: Trying to search for anything on results in a Javascript error: on line 313 of I'm on Chrome 30.0.1599.101 if that matters.
Weirdly, search results still appear if I search for most things, but not for anything starting with "sle" like "sleep".
This appears to be dying because of the method defined in . This shouldn't be showing up in the search because the entire module should be pruned as a result of it being private. This warrants more investigation...
Update: seems like it's not for "any" keyword as the OP states; for example or don't trigger any error for me. does for instance.
doesn't work either.
Happens to me too.
, , , , , , , and (and all shortened forms e.g. , ) don't work for me, but does work (i.e. shows results). The error I'm getting (on Firefox Nightly 29.0a1) is .
The error happens when a trait is implemented on a type that is pruned by one of the passes ( or ). The type was pruned but the implementation was not, so the search index included a method that referenced a missing type. fixes this.
Code change:
<ins> // Previously, in addition to the real cause of the problem as seen below, // the compiler would tell the user: // // ``` // error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or // predicates // ``` // // With this test, we check that only the relevant error is emitted. trait Foo {} impl<T> Foo for Bar<T> {} //~ ERROR cannot find type `Bar` in this scope fn main() {} </ins>

Related discussion:
text: The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.
Code change:
<ins> pub trait MyTrait { type Assoc; } pub fn foo<S, T>(_s: S, _t: T) where S: MyTrait, T: MyTrait<Assoc == S::Assoc>, //~^ ERROR: expected one of `,` or `>`, found `==` //~| ERROR: this trait takes 0 generic arguments but 1 generic argument was supplied { } fn main() {} </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. --I tried this code: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc
Code change:
let tokens = match *nt { Nonterminal::NtItem(ref item) => prepend_attrs(sess, &item.attrs, nt, item.tokens.as_ref()), Nonterminal::NtBlock(ref block) => convert_tokens(block.tokens.as_ref()), <del> Nonterminal::NtStmt(ref stmt) => prepend_attrs(sess, stmt.attrs(), nt, stmt.tokens()), </del> <ins> Nonterminal::NtStmt(ref stmt) => { let do_prepend = |tokens| prepend_attrs(sess, stmt.attrs(), nt, tokens); if let ast::StmtKind::Empty = stmt.kind { let tokens: TokenStream = tokenstream::TokenTree::token(token::Semi, stmt.span).into(); do_prepend(Some(&LazyTokenStream::new(tokens))) } else { do_prepend(stmt.tokens()) } } </ins> Nonterminal::NtPat(ref pat) => convert_tokens(pat.tokens.as_ref()), Nonterminal::NtTy(ref ty) => convert_tokens(ty.tokens.as_ref()), Nonterminal::NtIdent(ident, is_raw) => {

Related discussion:
text: This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened
Code change:
} bb0: { <del> StorageLive(_2);                 // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 ((_2 as Some).0: i32) = const 1_i32; // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 discriminant(_2) = 1;            // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 _1 = ((_2 as Some).0: i32);      // scope 0 at $DIR/issue-73223.rs:3:14: 3:15 StorageDead(_2);                 // scope 0 at $DIR/issue-73223.rs:5:6: 5:7 ((_3 as Some).0: i32) = _1;      // scope 1 at $DIR/issue-73223.rs:7:22: 7:27 </del> <ins> StorageLive(_1);                 // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 ((_1 as Some).0: i32) = const 1_i32; // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 discriminant(_1) = 1;            // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 _2 = ((_1 as Some).0: i32);      // scope 0 at $DIR/issue-73223.rs:3:14: 3:15 StorageDead(_1);                 // scope 0 at $DIR/issue-73223.rs:5:6: 5:7 ((_3 as Some).0: i32) = _2;      // scope 1 at $DIR/issue-73223.rs:7:22: 7:27 </ins> discriminant(_3) = 1;            // scope 1 at $DIR/issue-73223.rs:7:17: 7:28 <del> (_4.0: &i32) = &_1;              // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </del> <ins> (_4.0: &i32) = &_2;              // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> (_4.1: &i32) = const main::promoted[1]; // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL // ty::Const // + ty: &i32

Related discussion:
text: This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix
Code change:
// Create generics from the generics specified in the impl head. debug!("convert: ast_generics={:?}", generics); let def_id = ccx.tcx.map.local_def_id(it.id); <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_impl(ccx, generics); </ins> let mut ty_predicates = ty_generic_predicates_for_type_or_impl(ccx, generics); debug!("convert: impl_bounds={:?}", ty_predicates);

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<ins> // Test for #78438: ensure underline alignment with many tabs on the left, long line on the right // ignore-tidy-linelength // ignore-tidy-tab fn main() { let money = 42i32; match money { v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT //~^ ERROR variable `v` is not bound in all patterns v => println!("Enough money {}", v), } } </ins>

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
#[stable(feature = "rust1", since = "1.0.0")] pub use self::mutex::{Mutex, MutexGuard}; #[stable(feature = "rust1", since = "1.0.0")] <ins> #[allow(deprecated)] </ins> pub use self::once::{Once, OnceState, ONCE_INIT}; #[stable(feature = "rust1", since = "1.0.0")] pub use crate::sys_common::poison::{PoisonError, TryLockError, TryLockResult, LockResult};

Related discussion:
text: , anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new: