jiebi/CodeConvo huggingface dataset:
Code change:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

Related discussion:
text: } } <del> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx => { </del> <ins> (&ty::ty_param(ref a_p), &ty::ty_param(ref b_p)) if a_p.idx == b_p.idx && a_p.space == b_p.space => { </ins> Ok(a) }
Code change:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

Related discussion:
text: <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. use std::num::Num; trait BrokenAdd: Num { fn broken_add<T>(&self, rhs: T) -> Self { *self + rhs //~ ERROR mismatched types } } impl<T: Num> BrokenAdd for T {} pub fn main() { let foo: u8 = 0u8; let x: u8 = foo.broken_add("hello darkness my old friend".to_string()); println!("{}", x); } </ins>
Code change:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

Related discussion:
text: <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. trait Tr<T> { fn op(T) -> Self; } // these compile as if Self: Tr<U>, even tho only Self: Tr<Self or T> trait A:    Tr<Self> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<Self> } } trait B<T>: Tr<T> { fn test<U>(u: U) -> Self { Tr::op(u)   //~ ERROR expected Tr<U>, but found Tr<T> } } impl<T> Tr<T> for T { fn op(t: T) -> T { t } } impl<T> A for T {} fn main() { std::io::println(A::test((&7306634593706211700, 8))); } </ins>
Code change:
(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:

Related discussion:
text: <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. trait Tr { fn test<X>(u: X) -> Self { u   //~ ERROR mismatched types } } fn main() {} </ins>
Code change:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

Related discussion:
text: CFG_LIBDIR_RELATIVE=bin fi <ins> if [ "$CFG_OSTYPE" = "pc-mingw32" ] || [ "$CFG_OSTYPE" = "w64-mingw32" ] then CFG_LD_PATH_VAR=PATH CFG_OLD_LD_PATH_VAR=$PATH elif [ "$CFG_OSTYPE" = "Darwin" ] then CFG_LD_PATH_VAR=DYLD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$DYLD_LIBRARY_PATH else CFG_LD_PATH_VAR=LD_LIBRARY_PATH CFG_OLD_LD_PATH_VAR=$LD_LIBRARY_PATH fi </ins> flag uninstall "only uninstall from the installation prefix" opt verify 1 "verify that the installed binaries run correctly" valopt prefix "/usr/local" "set installation prefix"
Code change:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

Related discussion:
text: if [ -z "${CFG_UNINSTALL}" ] then msg "verifying platform can run binaries" <ins> export $CFG_LD_PATH_VAR="${CFG_SRC_DIR}/lib":$CFG_OLD_LD_PATH_VAR </ins> "${CFG_SRC_DIR}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then err "can't execute rustc binary on this platform" fi <ins> export $CFG_LD_PATH_VAR=$CFG_OLD_LD_PATH_VAR </ins> fi fi
Code change:
At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)

Related discussion:
text: done < "${CFG_SRC_DIR}/${CFG_LIBDIR_RELATIVE}/rustlib/manifest.in" # Sanity check: can we run the installed binaries? <ins> # # As with the verification above, make sure the right LD_LIBRARY_PATH-equivalent # is in place. Try first without this variable, and if that fails try again with # the variable. If the second time tries, print a hopefully helpful message to # add something to the appropriate environment variable. </ins> if [ -z "${CFG_DISABLE_VERIFY}" ] then msg "verifying installed binaries are executable" <del> "${CFG_PREFIX}/bin/rustc" --version > /dev/null </del> <ins> "${CFG_PREFIX}/bin/rustc" --version 2> /dev/null 1> /dev/null </ins> if [ $? -ne 0 ] then <del> ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" </del> <ins> export $CFG_LD_PATH_VAR="${CFG_PREFIX}/lib":$CFG_OLD_LD_PATH_VAR "${CFG_PREFIX}/bin/rustc" --version > /dev/null if [ $? -ne 0 ] then ERR="can't execute installed rustc binary. " ERR="${ERR}installation may be broken. " ERR="${ERR}if this is expected then rerun install.sh with `--disable-verify` " ERR="${ERR}or `make install` with `--disable-verify-install`" err "${ERR}" else echo echo "    please ensure '${CFG_PREFIX}/lib' is added to ${CFG_LD_PATH_VAR}" echo fi </ins> fi fi
Code change:
A fixed-length array expression with a repeat count with the high bit set and no suffix is incorrectly treated as a negative count. On a 64-bit machine: This results in
Can be easily fixed after landed
Seems that it is not an issue any more.
I'm thinking that if it behave differently on different platforms, is it making it an undefined behavior? And I think designating an exact behavior for UB cannot possibly be a breaking change?
This does not make it undefined behavior. It's very much defined behavior. If it were undefined behavior, then any or literal would be undefined behavior as well, because the range of valid values is architecture-dependent.

Related discussion:
text: <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. // error-pattern: too big for the current architecture #[cfg(target_pointer_width = "32")] fn main() { let x = [0usize; 0xffff_ffff]; } #[cfg(target_pointer_width = "64")] fn main() { let x = [0usize; 0xffff_ffff_ffff_ffff]; } </ins>
Code change:
We should record the names that users give complex types and use them when we can when reporting diagnostics.
WONTFIX (not require for bootstrapping; works correctly in rustc already).

Related discussion:
text: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done
Code change:
fails with vector v.
WONTFIX (not required for bootstrapping, reopen if somehow this re-emerges in rustc)

Related discussion:
text: rustup toolchain install --profile minimal nightly-${TOOLCHAIN} # Sanity check to see if the nightly exists echo nightly-${TOOLCHAIN} > rust-toolchain <del> echo "=> Uninstalling all old nighlies" </del> <ins> echo "=> Uninstalling all old nightlies" </ins> for nightly in $(rustup toolchain list | grep nightly | grep -v $TOOLCHAIN | grep -v nightly-x86_64); do rustup toolchain uninstall $nightly done
Code change:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

Related discussion:
text: <del> Subproject commit 2751bdcef125468ea2ee006c11992cd1405aebe5 </del> <ins> Subproject commit 34fca48ed284525b2f124bf93c51af36d6685492 </ins>
Code change:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

Related discussion:
text: <del> Subproject commit 388750b081c0893c275044d37203f97709e058ba </del> <ins> Subproject commit e3f3af69dce71cd37a785bccb7e58449197d940c </ins>
Code change:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

Related discussion:
text: <del> Subproject commit d43038932adeb16ada80e206d4c073d851298101 </del> <ins> Subproject commit ee7c676fd6e287459cb407337652412c990686c0 </ins>
Code change:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

Related discussion:
text: <del> Subproject commit 07e0df2f006e59d171c6bf3cafa9d61dbeb520d8 </del> <ins> Subproject commit c954202c1e1720cba5628f99543cc01188c7d6fc </ins>
Code change:
On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.

Related discussion:
text: <del> Subproject commit b123ab4754127d822ffb38349ce0fbf561f1b2fd </del> <ins> Subproject commit 08bb147d51e815b96e8db7ba4cf870f201c11ff8 </ins>
Code change:
The std docs should list: The version they were built with The build date They could be at the top or bottom of every page, or on a stand-alone page like About or Help. This may not be important on rust- where I think they are rebuilt with every push but it seems like a good idea. It might be more useful on other sites where it isn't rebuilt for every push.
I don't think this is a problem with std itself, since the version is in the URL (or it's master, which was built in the past 24 hours).
Not sure where you std docs URL doesn't list a version. I don't think it will be a problem for Rust long-term. Once stable, the address will probably be something like with version varying between versions.
Partly a dupe of
Yes, this is basically a dup of /

Related discussion:
text: **Source:** https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/config.rs[config.rs] <del> The <<_installation,Installation>> section contains details on configuration for some of the editors. </del> <ins> The <<installation,Installation>> section contains details on configuration for some of the editors. </ins> In general `rust-analyzer` is configured via LSP messages, which means that it's up to the editor to decide on the exact format and location of configuration files. Some clients, such as <<vs-code,VS Code>> or <<coc-rust-analyzer,COC plugin in Vim>> provide `rust-analyzer` specific configuration UIs. Others may require you to know a bit more about the interaction with `rust-analyzer`.
Code change:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

Related discussion:
text: let stability_index = time(time_passes, "stability index", (), |_| stability::Index::build(krate)); <ins> time(time_passes, "static item recursion checking", (), |_| middle::check_static_recursion::check_crate(&sess, krate, &def_map, &ast_map)); </ins> let ty_cx = ty::mk_ctxt(sess, type_arena, def_map,
Code change:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

Related discussion:
text: pub mod borrowck; pub mod cfg; pub mod check_const; <ins> pub mod check_static_recursion; </ins> pub mod check_loop; pub mod check_match; pub mod check_rvalues;
Code change:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

Related discussion:
text: // except according to those terms. <del> use driver::session::Session; </del> use middle::def::*; <del> use middle::resolve; </del> use middle::ty; use middle::typeck; use util::ppaux; use syntax::ast::*; <del> use syntax::{ast_util, ast_map}; </del> <ins> use syntax::ast_util; </ins> use syntax::visit::Visitor; use syntax::visit;
Code change:
Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.

Related discussion:
text: match it.node { ItemStatic(_, _, ref ex) => { v.inside_const(|v| v.visit_expr(&**ex)); <del> check_item_recursion(&v.tcx.sess, &v.tcx.map, &v.tcx.def_map, it); </del> } ItemEnum(ref enum_definition, _) => { for var in (*enum_definition).variants.iter() {