jiebi/CodeConvo huggingface dataset:
Code change:
is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.

Related discussion:
text: <ins> error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `[std::fmt::ArgumentV1<'_>]` --> $DIR/send-sync.rs:18:5 | 18 |     send(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `[std::fmt::ArgumentV1<'_>]`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because of the requirements on the impl of `std::marker::Send` for `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `send` error[E0277]: the trait bound `*mut std::ops::Fn() + 'static: std::marker::Sync` is not satisfied in `std::fmt::Arguments<'_>` --> $DIR/send-sync.rs:19:5 | 19 |     sync(format_args!("{:?}", c)); |     ^^^^ `*mut std::ops::Fn() + 'static` cannot be shared between threads safely | = help: within `std::fmt::Arguments<'_>`, the trait `std::marker::Sync` is not implemented for `*mut std::ops::Fn() + 'static` = note: required because it appears within the type `std::marker::PhantomData<*mut std::ops::Fn() + 'static>` = note: required because it appears within the type `core::fmt::Void` = note: required because it appears within the type `&core::fmt::Void` = note: required because it appears within the type `std::fmt::ArgumentV1<'_>` = note: required because it appears within the type `[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `&[std::fmt::ArgumentV1<'_>]` = note: required because it appears within the type `std::fmt::Arguments<'_>` = note: required by `sync` error: aborting due to 2 previous errors </ins>
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: #[macro_export] #[cfg(dox)] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: #[unstable(feature = "concat_idents_macro", issue = "29599")] #[macro_export] macro_rules! concat_idents { <del> ($($e:ident),*) => ({ /* compiler built-in */ }) </del> <ins> ($($e:ident),*) => ({ /* compiler built-in */ }); ($($e:ident,)*) => ({ /* compiler built-in */ }); </ins> } /// Concatenates literals into a static string slice.
Code change:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged

Related discussion:
text: /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///
Code change:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: self.search_mut(k).into_occupied_bucket().map(|bucket| pop_internal(bucket).1) } <ins> /// Removes a key from the map, returning the stored key and value if the /// key was previously in the map. /// /// The key may be any borrowed form of the map's key type, but /// [`Hash`] and [`Eq`] on the borrowed form *must* match those for /// the key type. /// /// [`Eq`]: ../../std/cmp/trait.Eq.html /// [`Hash`]: ../../std/hash/trait.Hash.html /// /// # Examples /// /// ``` /// #![feature(hash_map_remove_entry)] /// use std::collections::HashMap; /// /// # fn main() { /// let mut map = HashMap::new(); /// map.insert(1, "a"); /// assert_eq!(map.remove_entry(&1), Some((1, "a"))); /// assert_eq!(map.remove(&1), None); /// # } /// ``` #[unstable(feature = "hash_map_remove_entry", issue = "46344")] pub fn remove_entry<Q: ?Sized>(&mut self, k: &Q) -> Option<(K, V)> where K: Borrow<Q>, Q: Hash + Eq { if self.table.size() == 0 { return None; } self.search_mut(k) .into_occupied_bucket() .map(|bucket| { let (k, v, _) = pop_internal(bucket); (k, v) }) } </ins> /// Retains only the elements specified by the predicate. /// /// In other words, remove all pairs `(k, v)` such that `f(&k,&mut v)` returns `false`.
Code change:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: } #[test] <del> fn test_pop() { </del> <ins> fn test_remove() { </ins> let mut m = HashMap::new(); m.insert(1, 2); assert_eq!(m.remove(&1), Some(2));
Code change:
We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.

Related discussion:
text: } #[test] <ins> fn test_remove_entry() { let mut m = HashMap::new(); m.insert(1, 2); assert_eq!(m.remove_entry(&1), Some((1, 2))); assert_eq!(m.remove(&1), None); } #[test] </ins> fn test_iterate() { let mut m = HashMap::with_capacity(4); for i in 0..32 {
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: unsafe { let g = get_static(cx, def_id); <del> let v = match ::mir::codegen_static_initializer(cx, def_id) { </del> <ins> let (v, alloc) = match ::mir::codegen_static_initializer(cx, def_id) { </ins> Ok(v) => v, // Error has already been reported Err(_) => return,
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: if attr::contains_name(attrs, "thread_local") { llvm::set_thread_local_mode(g, cx.tls_model); <ins> // Do not allow LLVM to change the alignment of a TLS on macOS. // // By default a global's alignment can be freely increased. // This allows LLVM to generate more performant instructions // e.g. using load-aligned into a SIMD register. // // However, on macOS 10.10 or below, the dynamic linker does not // respect any alignment given on the TLS (radar 24221680). // This will violate the alignment assumption, and causing segfault at runtime. // // This bug is very easy to trigger. In `println!` and `panic!`, // the `LOCAL_STDOUT`/`LOCAL_STDERR` handles are stored in a TLS, // which the values would be `mem::replace`d on initialization. // The implementation of `mem::replace` will use SIMD // whenever the size is 32 bytes or higher. LLVM notices SIMD is used // and tries to align `LOCAL_STDOUT`/`LOCAL_STDERR` to a 32-byte boundary, // which macOS's dyld disregarded and causing crashes // (see issues #51794, #51758, #50867, #48866 and #44056). // // To workaround the bug, we trick LLVM into not increasing // the global's alignment by explicitly assigning a section to it // (equivalent to automatically generating a `#[link_section]` attribute). // See the comment in the `GlobalValue::canIncreaseAlignment()` function // of `lib/IR/Globals.cpp` for why this works. // // When the alignment is not increased, the optimized `mem::replace` // will use load-unaligned instructions instead, and thus avoiding the crash. // // We could remove this hack whenever we decide to drop macOS 10.10 support. if cx.tcx.sess.target.target.options.is_like_osx { let sect_name = if alloc.bytes.iter().all(|b| *b == 0) { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_bss0") } else { CStr::from_bytes_with_nul_unchecked(b"__DATA,__thread_data0") }; llvm::LLVMSetSection(g, sect_name.as_ptr()); } </ins> } base::set_link_section(cx, g, attrs);
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: pub fn codegen_static_initializer<'a, 'tcx>( cx: &CodegenCx<'a, 'tcx>, def_id: DefId) <del> -> Result<ValueRef, Lrc<ConstEvalErr<'tcx>>> </del> <ins> -> Result<(ValueRef, &'tcx Allocation), Lrc<ConstEvalErr<'tcx>>> </ins> { let instance = ty::Instance::mono(cx.tcx, def_id); let cid = GlobalId {
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: ConstValue::ByRef(alloc, n) if n.bytes() == 0 => alloc, _ => bug!("static const eval returned {:#?}", static_), }; <del> Ok(const_alloc_to_llvm(cx, alloc)) </del> <ins> Ok((const_alloc_to_llvm(cx, alloc), alloc)) </ins> } impl<'a, 'tcx> FunctionCx<'a, 'tcx> {
Code change:
Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?

Related discussion:
text: <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. // ignore-tidy-linelength // only-macos // no-system-llvm // min-llvm-version 6.0 // compile-flags: -O #![crate_type = "rlib"] #![feature(thread_local)] // CHECK: @STATIC_VAR_1 = internal thread_local unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_1: [u32; 8] = [0; 8]; // CHECK: @STATIC_VAR_2 = internal thread_local unnamed_addr global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4 #[no_mangle] #[allow(private_no_mangle_statics)] #[thread_local] static mut STATIC_VAR_2: [u32; 8] = [4; 8]; #[no_mangle] pub unsafe fn f(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_1) } #[no_mangle] pub unsafe fn g(x: &mut [u32; 8]) { std::mem::swap(x, &mut STATIC_VAR_2) } </ins>