jiebi/CodeConvo huggingface dataset:
Code change:
pub fn hash_hir_item_like<F: FnOnce(&mut Self)>(&mut self, item_attrs: &[ast::Attribute], <ins> is_const: bool, </ins> f: F) { let prev_overflow_checks = self.overflow_checks_enabled; <del> if attr::contains_name(item_attrs, "rustc_inherit_overflow_checks") { </del> <ins> if is_const || attr::contains_name(item_attrs, "rustc_inherit_overflow_checks") { </ins> self.overflow_checks_enabled = true; } let prev_hash_node_ids = self.node_id_hashing_mode;

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
} /// Parse a 'for' .. 'in' expression ('for' token already eaten) <del> pub fn parse_for_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { </del> <ins> pub fn parse_for_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> // Parse: `for <src_pat> in <src_expr> <src_loop_block>` <del> let lo = self.last_span.lo; </del> let pat = try!(self.parse_pat_nopanic()); try!(self.expect_keyword(keywords::In)); let expr = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let loop_block = try!(self.parse_block()); let hi = self.last_span.hi; <del> Ok(self.mk_expr(lo, hi, ExprForLoop(pat, expr, loop_block, opt_ident))) </del> <ins> Ok(self.mk_expr(span_lo, hi, ExprForLoop(pat, expr, loop_block, opt_ident))) </ins> } /// Parse a 'while' or 'while let' expression ('while' token already eaten) <del> pub fn parse_while_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { </del> <ins> pub fn parse_while_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> if self.token.is_keyword(keywords::Let) { <del> return self.parse_while_let_expr(opt_ident); </del> <ins> return self.parse_while_let_expr(opt_ident, span_lo); </ins> } <del> let lo = self.last_span.lo; </del> let cond = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let body = try!(self.parse_block()); let hi = body.span.hi; <del> return Ok(self.mk_expr(lo, hi, ExprWhile(cond, body, opt_ident))); </del> <ins> return Ok(self.mk_expr(span_lo, hi, ExprWhile(cond, body, opt_ident))); </ins> } /// Parse a 'while let' expression ('while' token already eaten) <del> pub fn parse_while_let_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { let lo = self.last_span.lo; </del> <ins> pub fn parse_while_let_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> try!(self.expect_keyword(keywords::Let)); let pat = try!(self.parse_pat_nopanic()); try!(self.expect(&token::Eq)); let expr = try!(self.parse_expr_res(Restrictions::RESTRICTION_NO_STRUCT_LITERAL)); let body = try!(self.parse_block()); let hi = body.span.hi; <del> return Ok(self.mk_expr(lo, hi, ExprWhileLet(pat, expr, body, opt_ident))); </del> <ins> return Ok(self.mk_expr(span_lo, hi, ExprWhileLet(pat, expr, body, opt_ident))); </ins> } <del> pub fn parse_loop_expr(&mut self, opt_ident: Option<ast::Ident>) -> PResult<P<Expr>> { let lo = self.last_span.lo; </del> <ins> pub fn parse_loop_expr(&mut self, opt_ident: Option<ast::Ident>, span_lo: BytePos) -> PResult<P<Expr>> { </ins> let body = try!(self.parse_block()); let hi = body.span.hi; <del> Ok(self.mk_expr(lo, hi, ExprLoop(body, opt_ident))) </del> <ins> Ok(self.mk_expr(span_lo, hi, ExprLoop(body, opt_ident))) </ins> } fn parse_match_expr(&mut self) -> PResult<P<Expr>> {

Related discussion:
text: Rustc's parser does not include a loop's label in its span. So the span associated to the expression will contain only cc
Code change:
<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. // include file for issue-21146.rs parse_error </ins>

Related discussion:
text: Testcase: : : Output: Should output, instead, the parse errors from . Probably misplacing the diagnostic emitter somehow, when creating the nested parser for the included source, and doesn't have an .
(I suspect this is an easy fix, but am not quite sure)
Code change:
"list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Related discussion:
text: Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.
Code change:
"list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Related discussion:
text: Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).
Code change:
"list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Related discussion:
text: I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.
Code change:
"list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Related discussion:
text: Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.
Code change:
"list" will list all of the available passes", "NAMES"), optopt("", "llvm-args", "A list of arguments to pass to llvm, comma  separated", "ARGS"), <ins> optflag("", "no-rpath", "Disables setting the rpath in libs/exes"), </ins> optopt( "",  "out-dir", "Write output to compiler-chosen filename in <dir>", "DIR"),

Related discussion:
text: I suspect and have a more concrete notion about this.
I don't have anything much to add to this despite it coming up for triage today. I think it has to be fixed still, I'm still happy to do it via whatever combination of static linking by default and use of is sufficient for packagers, and I haven't seen any clear movement on it in the meantime.
accepted for backwards-compatible milestone
I'm getting worried that we won't resolve this for 1.0. I agree this is important to fix. Here's my current suggestion: Modify the build system to once again set LDLIBRARYPATH/PATH to find the appropriate dynamic libraries. Add a flag to rustc to disable rpath Add a configure flag to disable rpathing the rust build itself. Packagers can use this to do whatever they want. With this logic the rust package itself could avoid rpath where distros have their own way of dealing with library paths. The rustc installed by these distros would still be rpathing user's crates for the sake of convenience. Is this an acceptable compromise or do distros want us to completely disable rpath? I'm afraid that doing so would provide an inconsistent developer experience depending on how rustc is acquired; if we need to do that then we instead must find a way to completely eliminate rpath.
If we start to just statically link everything by default then rpath becomes much less important and we can just say it's up to users to figure it out if they opt into dynamic linking.
I think we should completely remove absolute rpaths. It's okay to have $ORIGIN-based ones but it may not be a good default. I'm not sure what the answer is to that, but agree that static linking basically resolves this.
It doesn't appear that this is fully working. There are still rpaths in the binaries when configured with even though the flag for rustc does work. /usr/bin/rustc: RPATH=$ORIGIN/../lib:/build/rust-git/src/rust/x8664-unknown-linux-gnu/stage1/lib/rustlib/x8664-unknown-linux-gnu/lib:/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
What steps did you follow to having the rpath show up? I thought I double checked on linux that the configure flag worked, but I may have overlooked something.
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. // Test that attempts to implicitly coerce a value into an // object respect the lifetime bound on the object type. fn a(v: &[u8]) -> Box<Clone + 'static> { let x: Box<Clone + 'static> = box v; //~ ERROR does not outlive x } fn b(v: &[u8]) -> Box<Clone + 'static> { box v //~ ERROR does not outlive } fn c(v: &[u8]) -> Box<Clone> { box v // OK thanks to lifetime elision } fn d<'a,'b>(v: &'a [u8]) -> Box<Clone+'b> { box v //~ ERROR does not outlive } fn e<'a:'b,'b>(v: &'a [u8]) -> Box<Clone+'b> { box v // OK, thanks to 'a:'b } fn main() { } </ins>

Related discussion:
text: This should not compile, since is for some non- and thus will contain as well. It compiles fine however and results in the varying output depending on the optimization level (which shows that this is an UB out of the "safe" code). Tested with and playpen.
A more self-contained example that shouldn't type-check:
It seems that this has been possible since generalized lifetime bounds went in.
Huh. This was supposed to be fixed. I'll take a look.
P-backcompat-lang, 1.0
OK, simple oversight. PR coming soon. Amazing we have no test for this. It occurs only with coercions. (In general, this code path could be cleaned up, and will be as part of implementing generalized where clauses, making these kinds of oversights harder to do.)
Code change:
// down as much as possible (without going negative), and then // adding back in whatever we couldn't factor into steals. Some(data) => { <del> self.steals += 1; </del> if self.steals > MAX_STEALS { match self.cnt.swap(0, atomics::SeqCst) { DISCONNECTED => {

Related discussion:
text: PRs are bouncing due to test timeouts. Nothing has landed since cc
Very, very unfortunately, just landed. This means that the breakage is not unconditional.
Segfault!
had also been reporting segfaults on master.
I got a segfault on
What is causing this?
Weird, seemed to make it through.
This appears to be because of a channel deadlock. Investigating now.
Fixed the deadlock, investigating the segfault now.
Code change:
/// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::encode; /// /// let url = encode("https://example.com/Rust (programming language)");

Related discussion:
text: Users should use the cargo-ified Deprecate for a release or two then delete. cc
:+1:
Related:
I tried this: Hoping to deprecate the whole crate, but then building this program does not emit any warning: I expected a deprecation warning on the line. Is there another way to achieve this, or do I need to annotate individual items in the crate?
That should have worked, but you may need to remove the annotation above (they may be conflicting). I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).
Removing worked, thanks. Should this deprecation go through the RFC process, or can I assume that the team wants it since filed this issue? The documentation at explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. vs ) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)
Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here. I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.
Code change:
#[allow(unused_variables)] fn main() { let x2: i8 = --128; //~ error: literal out of range for i8 <ins> //~^ error: attempted to negate with overflow </ins> let x = -3.40282348e+38_f32; //~ error: literal out of range for f32 let x =  3.40282348e+38_f32; //~ error: literal out of range for f32

Related discussion:
text: This is clearly ridiculous, but rustc is perfectly happy with it. Regression from 1.9.
prints . Using the constant in any other way, e.g. errors out:
cc is that fallout from your new const eval?
I haven't removed anything, not that I can think of, to cause this.
Then it's very likely fallout from (skipping double negations)
The remaining error in that testcase feels wrong. should, IMO, be - the literal is in range, but the negation overflows.
Actually I think it should be valid code, but yield , at least that's what the original literal out of range lints do
But overflows when negating, which is an error. Why should it be different than ?
I have no particular opinion on this. But the lint has code handling double negations: (it's treating double negations as if they weren't there at all)
The double negation is not the issue here. The value of evaluates to , as expected. But consider the following code: This will also compile just fine and print . It goes wrong in the cast . Rust doesn't check if cast overflows, so the value becomes .  can be changed to disallow casts that fail. (I'd be happy to implement this myself.) Or we can accept that these casts are can overflow silently.
I believe the issue is that --128 (aka 128) is an intermediate result of the computation that is out of bounds for the i8. EDIT: The issue is about the fact that the compiler doesn't complain.
jup, that was a misunderstanding of some code on my part + the issue that processing HIR works the wrong way around (you start with the outer most expression). Reverting should do the job
I thought that it was intended that would succesfully evaluate to . (That rustc knows that it's overflowing, but is smart to know that double negation will fix it in the end.) Pretend I said nothing.