jiebi/CodeConvo huggingface dataset:
Change:
When a type has no impl, it fields appear to be destructed in order of declaration. When a type does have a impl, that order is apparently reversed. This is very surprising. Example: Prints:
cc who first hit this bug.
The LLVM IR for the Drop glue for : The LLVM IR for the Drop glue for : I don't know why it's getting pointers to each field before calling , they're not used until the cleanup, and they're cleaned up in reverse order. It's also, for some reason, grabbing a pointer to the drop flag (), even though it doesn't use it.
Nominating. Seems pretty strange.
I have an approved commit for this already, it's just failing on the pretty-rpass test at the moment.
I'm OK with disabling the test. Going forward the pretty printer should mainly be used for compiler diagnostics and rustfmt should cover the reformatting use cases, IMO.

Discussion:
let args = vec!(self_arg); // Add all the fields as a value which needs to be cleaned at the end of <del> // this scope. for (i, ty) in st.fields.iter().enumerate() { </del> <ins> // this scope. Iterate in reverse order so a Drop impl doesn't reverse // the order in which fields get dropped. for (i, ty) in st.fields.iter().enumerate().rev() { </ins> let llfld_a = adt::struct_field_ptr(variant_cx, &*st, value, i, false); variant_cx.fcx.schedule_drop_mem(cleanup::CustomScope(field_scope), llfld_a, *ty);

<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. // ignore-pretty #![feature(unsafe_destructor)] use std::rc::Rc; use std::cell::Cell; struct Field { number: uint, state: Rc<Cell<uint>> } impl Field { fn new(number: uint, state: Rc<Cell<uint>>) -> Field { Field { number: number, state: state } } } #[unsafe_destructor] // because Field isn't Send impl Drop for Field { fn drop(&mut self) { println!("Dropping field {}", self.number); assert_eq!(self.state.get(), self.number); self.state.set(self.state.get()+1); } } struct NoDropImpl { _one: Field, _two: Field, _three: Field } struct HasDropImpl { _one: Field, _two: Field, _three: Field } #[unsafe_destructor] // because HasDropImpl isn't Send impl Drop for HasDropImpl { fn drop(&mut self) { println!("HasDropImpl.drop()"); assert_eq!(self._one.state.get(), 0); self._one.state.set(1); } } pub fn main() { let state = Rc::new(Cell::new(1)); let noImpl = NoDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(noImpl); assert_eq!(state.get(), 4); state.set(0); let hasImpl = HasDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(hasImpl); assert_eq!(state.get(), 4); } </ins>
Change:
This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016

Discussion:
use std::rc::Rc; use std::{i8, i16, i32, i64}; use syntax::abi::{X86, X86_64, Arm, Mips, Mipsel, Rust, RustCall}; <del> use syntax::abi::{RustIntrinsic, Abi}; </del> <ins> use syntax::abi::{RustIntrinsic, Abi, OsWindows}; </ins> use syntax::ast_util::{local_def, is_local}; use syntax::attr::AttrMetaMethods; use syntax::attr;

&ccx.int_type); let llfn = decl_cdecl_fn(ccx, "main", llfty, ty::mk_nil()); <ins> // FIXME: #16581: Marking a symbol in the executable with `dllexport` // linkage forces MinGW's linker to output a `.reloc` section for ASLR if ccx.sess().targ_cfg.os == OsWindows { unsafe { llvm::LLVMRustSetDLLExportStorageClass(llfn) } } </ins> let llbb = "top".with_c_str(|buf| { unsafe { llvm::LLVMAppendBasicBlockInContext(ccx.llcx, llfn, buf)
Change:
This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016

Discussion:
// Mark all dynamic libraries and executables as compatible with ASLR // FIXME #17098: ASLR breaks gdb <del> // cmd.arg("-Wl,--dynamicbase"); </del> <ins> if sess.opts.debuginfo == NoDebugInfo { cmd.arg("-Wl,--dynamicbase"); } </ins> // Mark all dynamic libraries and executables as compatible with the larger 4GiB address // space available to x86 Windows binaries on x86_64.
Change:
This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016

Discussion:
"-fno-use-linker-plugin".to_string(), // Always enable DEP (NX bit) when it is available "-Wl,--nxcompat".to_string(), <ins> // Enable ASLR "-Wl,--dynamicbase".to_string(), // ASLR will rebase it anyway so leaving that option enabled only leads to confusion "-Wl,--disable-auto-image-base".to_string(), </ins> ], );

pub fn target() -> TargetResult { let mut base = super::windows_gnu_base::opts(); base.cpu = "x86-64".to_string(); <del> base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); </del> <ins> let gcc_pre_link_args = base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap(); gcc_pre_link_args.push("-m64".to_string()); // Use high-entropy 64 bit address space for ASLR gcc_pre_link_args.push("-Wl,--high-entropy-va".to_string()); </ins> base.pre_link_args .insert(LinkerFlavor::Lld(LldFlavor::Ld), vec!["-m".to_string(), "i386pep".to_string()]); base.max_atomic_width = Some(64);

pub fn target() -> TargetResult { let mut base = super::windows_uwp_gnu_base::opts(); base.cpu = "x86-64".to_string(); <del> base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); </del> <ins> let gcc_pre_link_args = base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap(); gcc_pre_link_args.push("-m64".to_string()); // Use high-entropy 64 bit address space for ASLR gcc_pre_link_args.push("-Wl,--high-entropy-va".to_string()); </ins> base.pre_link_args .insert(LinkerFlavor::Lld(LldFlavor::Ld), vec!["-m".to_string(), "i386pep".to_string()]); base.max_atomic_width = Some(64);
Change:
As titled. Although slices support the operator, it does not implement , so one cannot pass in a slice in the following example:
I'm somewhat inclined to think we could just remove the built-in indexing from entirely and thus remove/reduce the need for the special lang-items, although there's at least three considerations: the failure message for out-of-bounds indexing would be less informative (no file/line information), but debugging any other (e.g. ) already requires a debugger to get this info, so maybe it's not so bad. can't yet implement properly, so this would still need built-in support with (and thus the out-of-bounds failure lang items can't be entirely removed just yet), unless implicit coercions will work. needs to be fixed before will work properly (and I guess DST would make it work more nicely). Users would theoretically not see a change, since this would all happen inside (and ).
It's not possible due to lack of CTFE.
cc me
Should I send a PR implementing / for now, and we can evaluate later removing the built-in indexing? I already tested that PR, and the built-in indexing is preferred in the operation , but one go through the trait using .
Yes, please go ahead and do so. Thanks!

Discussion:
* ``` */ #[lang="index"] <del> pub trait Index<Index, Sized? Result> { </del> <ins> pub trait Index<Index, Sized? Result> for Sized? { </ins> /// The method for the indexing (`Foo[Bar]`) operation fn index<'a>(&'a self, index: &Index) -> &'a Result; }

* ``` */ #[lang="index_mut"] <del> pub trait IndexMut<Index, Result> { </del> <ins> pub trait IndexMut<Index, Result> for Sized? { </ins> /// The method for the indexing (`Foo[Bar]`) operation fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result; }

#[inline] #[experimental = "not triaged yet"] fn is_empty(&self) -> bool { self.len() == 0 } /// Returns a mutable reference to the element at the given index, /// or `None` if the index is out of bounds #[unstable = "waiting on final error conventions"]

} } <ins> impl<T> ops::Index<uint, T> for [T] { fn index(&self, &index: &uint) -> &T { assert!(index < self.len()); unsafe { mem::transmute(self.repr().data.offset(index as int)) } } } impl<T> ops::IndexMut<uint, T> for [T] { fn index_mut(&mut self, &index: &uint) -> &mut T { assert!(index < self.len()); unsafe { mem::transmute(self.repr().data.offset(index as int)) } } } </ins> impl<T> ops::Slice<uint, [T]> for [T] { #[inline] fn as_slice_<'a>(&'a self) -> &'a [T] {
Change:
MinGW-w64 doesn't expose the necessary flag yet, so I'll look into adding it to their linker. It should be as easy as adding support for an extra flag there and then passing the switch from the Rust compiler.
gdb-patches 301'd to the binutils list: which accepted the patch:
closing in favor of
This is a separate issue from .
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016

Discussion:
"-fno-use-linker-plugin".to_string(), // Always enable DEP (NX bit) when it is available "-Wl,--nxcompat".to_string(), <ins> // Enable ASLR "-Wl,--dynamicbase".to_string(), // ASLR will rebase it anyway so leaving that option enabled only leads to confusion "-Wl,--disable-auto-image-base".to_string(), </ins> ], );

pub fn target() -> TargetResult { let mut base = super::windows_gnu_base::opts(); base.cpu = "x86-64".to_string(); <del> base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); </del> <ins> let gcc_pre_link_args = base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap(); gcc_pre_link_args.push("-m64".to_string()); // Use high-entropy 64 bit address space for ASLR gcc_pre_link_args.push("-Wl,--high-entropy-va".to_string()); </ins> base.pre_link_args .insert(LinkerFlavor::Lld(LldFlavor::Ld), vec!["-m".to_string(), "i386pep".to_string()]); base.max_atomic_width = Some(64);

pub fn target() -> TargetResult { let mut base = super::windows_uwp_gnu_base::opts(); base.cpu = "x86-64".to_string(); <del> base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap().push("-m64".to_string()); </del> <ins> let gcc_pre_link_args = base.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap(); gcc_pre_link_args.push("-m64".to_string()); // Use high-entropy 64 bit address space for ASLR gcc_pre_link_args.push("-Wl,--high-entropy-va".to_string()); </ins> base.pre_link_args .insert(LinkerFlavor::Lld(LldFlavor::Ld), vec!["-m".to_string(), "i386pep".to_string()]); base.max_atomic_width = Some(64);
Change:
Assigning to a mutable vector causes it to be modified in-place even if the right side of the assignment references it. On IRC, pointed me to , which might be related.
Nominating. This may not be a 1.0 backcompat-lang issue though as it seems fairly rare.
Same thing with structs:
OK, same thing happens with enums, which is a bit more serious since it now affects memory safety.
I believe this problem is in trans -- it is supposed to used a temporary buffer for these sorts of cases, but obviously that check is not working correctly.
Team believes this to be a miscompilation issue (and not, as we feared at first, a failure of the borrow-checker to reject an incorrect program). That is, these programs should be compilable; the problem is that the generated code is wrong. P-high, not 1.0.
All of the code examples from this ticket seem to work now: So I think this just needs regression tests.

Discussion:
<ins> // Copyright 2015 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 t = [1; 2]; t = [t[1] * 2, t[0] * 2]; assert_eq!(&t[..], &[2, 2]); } </ins>

<ins> // Copyright 2015 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. struct A { pub x: u32, pub y: u32, } fn main() { let mut a = A { x: 1, y: 1 }; a = A { x: a.y * 2, y: a.x * 2 }; assert_eq!(a.x, 2); assert_eq!(a.y, 2); } </ins>

<ins> // Copyright 2015 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. #[derive(Debug)] enum Foo { Bar(u32, u32), Baz(&'static u32, &'static u32) } static NUM: u32 = 100; fn main () { let mut b = Foo::Baz(&NUM, &NUM); b = Foo::Bar(f(&b), g(&b)); } static FNUM: u32 = 1; fn f (b: &Foo) -> u32 { FNUM } static GNUM: u32 = 2; fn g (b: &Foo) -> u32 { GNUM } </ins>
Change:
Extracted from an issue I encountered upgrading to Rust master. : : It seems like more or less every part of this code is necessary to hit the bug. Here's the result: (This has my modifications to give a marginally more useful error message.) The failure happens when when handling the case. What I actually get building is a failure of the preceding assertion regarding crate IDs. I didn't find a small reproducer for that assertion failure, but this bug is likely to be related.
cc me
(Slightly) simpler example: This appears to be related to AST being inlined cross-crate, and the internals (cc since desugaring it to the equivalent doesn't ICE. It also requires that is a method, a freestanding function stops the ICE.
Cool, for now I'll go with the workaround of desugaring the loop myself.

Discussion:
<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. #![crate_type = "lib"] pub struct TreeBuilder<H>; impl<H> TreeBuilder<H> { pub fn process_token(&mut self) { match self { _ => for _y in *self {} } } } impl<H> Iterator<H> for TreeBuilder<H> { fn next(&mut self) -> Option<H> { None } } </ins>

<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. // aux-build:issue-16643.rs extern crate i = "issue-16643"; pub fn main() { i::TreeBuilder::<uint>.process_token(); } </ins>
Change:
We have a function str::fromcstr but it assumes that C string is null-terminated. The only way I see to build a string from a non-null-terminated buffer is using str::frombytes(vec::from_buf()) which requires an extra copy of the string.

Discussion:
from_char, from_chars, from_cstr, <ins> from_cstr_len, </ins> concat, connect,

} /* <ins> Function: from_cstr_len Create a Rust string from a C string of the given length */ unsafe fn from_cstr_len(cstr: sbuf, len: uint) -> str { let res = []; let start = cstr; let curr = start; let i = 0u; while i < len { vec::push(res, *curr); i += 1u; curr = ptr::offset(start, i); } ret from_bytes(res); } /* </ins> Function: concat Concatenate a vector of strings

} #[test] <ins> fn test_from_cstr_len() unsafe { let a = [65u8, 65u8, 65u8, 65u8, 65u8, 65u8, 65u8, 0u8]; let b = vec::to_ptr(a); let c = from_cstr_len(b, 3u); assert (c == "AAA"); } #[test] </ins> fn test_as_buf() unsafe { let a = "Abcdefg"; let b = as_buf(a, {|buf| assert (*buf == 65u8); 100 });
Change:
For example
this actually appears to be currently fixed to me; I don't doubt that your PR has value, but can you explain which of the cases reported on this ticket is currently failing for you?
Ah, I hadn't actually checked if this issue was still valid! But it seems you're right and I don't think my PR is even relevant after the recent changes to constant evaluation. Closing, thanks.
Well, sorry, FWIW, this A-needstest.

Discussion:
<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() { const X: u8 = 0; let out: u8 = match 0u8 { X => 99, b't' => 1, 1u8 => 2, _ => 3, }; assert_eq!(out, 99); } </ins>
Change:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.

Discussion:
KeyMustBeAString, ExpectedColon, TrailingCharacters, <ins> TrailingComma, </ins> InvalidEscape, InvalidUnicodeCodePoint, LoneLeadingSurrogateInHexEscape,

KeyMustBeAString => "key must be a string", ExpectedColon => "expected `:`", TrailingCharacters => "trailing characters", <ins> TrailingComma => "trailing comma", </ins> InvalidEscape => "invalid escape", UnrecognizedHex => "invalid u escape (unrecognized hex)", NotFourDigit => "invalid u escape (not four digits)",

fn parse_object(&mut self, first: bool) -> JsonEvent { if self.ch_is('}') { if !first { <del> self.stack.pop(); </del> <ins> if self.stack.is_empty() { return self.error_event(TrailingComma); } else { self.stack.pop(); } </ins> } if self.stack.is_empty() { self.state = ParseBeforeFinish;

F64Value, StringValue, NullValue, SyntaxError, Key, Index, Stack, InvalidSyntax, InvalidNumber, EOFWhileParsingObject, EOFWhileParsingList, EOFWhileParsingValue, EOFWhileParsingString, KeyMustBeAString, ExpectedColon, <del> TrailingCharacters}; </del> <ins> TrailingCharacters, TrailingComma}; </ins> use std::{i64, u64, f32, f64, io}; use std::collections::TreeMap;

} } } #[test] #[ignore(cfg(target_word_size = "32"))] // FIXME(#14064) fn test_read_object_streaming() {

assert_eq!(last_event("{"a":1"),   Error(SyntaxError(EOFWhileParsingObject, 1, 7))); assert_eq!(last_event("{"a":1 1"), Error(SyntaxError(InvalidSyntax,         1, 8))); assert_eq!(last_event("{"a":1,"),  Error(SyntaxError(EOFWhileParsingObject, 1, 8))); <ins> assert_eq!(last_event("{"a":1,}"), Error(SyntaxError(TrailingComma, 1, 8))); </ins> assert_stream_equal( "{}",