jiebi/CodeConvo huggingface dataset:
Code change:
// FIXME (#2397): At some point we want to rpath our guesses as to // where extern libraries might live, based on the // addl_lib_search_paths <del> args.push_all(rpath::get_rpath_flags(sess, out_filename)); </del> <ins> if !sess.opts.no_rpath { args.push_all(rpath::get_rpath_flags(sess, out_filename)); } </ins> // Finally add all the linker arguments provided on the command line along // with any #[link_args] attributes found inside the crate

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:
// FIXME (#2397): At some point we want to rpath our guesses as to // where extern libraries might live, based on the // addl_lib_search_paths <del> args.push_all(rpath::get_rpath_flags(sess, out_filename)); </del> <ins> if !sess.opts.no_rpath { args.push_all(rpath::get_rpath_flags(sess, out_filename)); } </ins> // Finally add all the linker arguments provided on the command line along // with any #[link_args] attributes found inside the crate

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:
// FIXME (#2397): At some point we want to rpath our guesses as to // where extern libraries might live, based on the // addl_lib_search_paths <del> args.push_all(rpath::get_rpath_flags(sess, out_filename)); </del> <ins> if !sess.opts.no_rpath { args.push_all(rpath::get_rpath_flags(sess, out_filename)); } </ins> // Finally add all the linker arguments provided on the command line along // with any #[link_args] attributes found inside the crate

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:
impl<'tcx> GATSubstCollector<'tcx> { fn visit<T: TypeFoldable<'tcx>>( <ins> tcx: TyCtxt<'tcx>, </ins> gat: DefId, t: T, ) -> (FxHashSet<(ty::Region<'tcx>, usize)>, FxHashSet<(Ty<'tcx>, usize)>) { <del> let mut visitor = GATSubstCollector { gat, regions: FxHashSet::default(), types: FxHashSet::default() }; </del> <ins> let mut visitor = GATSubstCollector { tcx, gat, regions: FxHashSet::default(), types: FxHashSet::default(), }; </ins> t.visit_with(&mut visitor); (visitor.regions, visitor.types) }

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Slightly minimized:
I understand the issue here, and have a solution but it might not be optimal. claim
Code change:
fn <a href="#tymethod.poll_write" class="fn">poll_write</a>( self, cx: &amp;mut <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="struct" href="{{channel}}/alloc/string/struct.String.html" title="struct alloc::string::String">String</a>&gt;, <del> buf: &amp;mut [<a class="primitive" href="{{channel}}/std/primitive.usize.html">usize</a>] </del> <ins> buf: &amp;mut [<a class="primitive" href="{{channel}}/std/primitive.usize.html">usize</a>], </ins> ) -&gt; <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="enum" href="{{channel}}/core/result/enum.Result.html" title="enum core::result::Result">Result</a>&lt;<a class="primitive" href="{{channel}}/std/primitive.usize.html">usize</a>, <a class="struct" href="struct.Error.html" title="struct foo::Error">Error</a>&gt;&gt;; <span class="item-spacer" />    fn <a href="#tymethod.poll_flush" class="fn">poll_flush</a>(self, cx: &amp;mut <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="struct" href="{{channel}}/alloc/string/struct.String.html" title="struct alloc::string::String">String</a>&gt;) -&gt; <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="enum" href="{{channel}}/core/result/enum.Result.html" title="enum core::result::Result">Result</a>&lt;<a class="primitive" href="{{channel}}/std/primitive.unit.html">()</a>, <a class="struct" href="struct.Error.html" title="struct foo::Error">Error</a>&gt;&gt;; <span class="item-spacer" />    fn <a href="#tymethod.poll_close" class="fn">poll_close</a>(self, cx: &amp;mut <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="struct" href="{{channel}}/alloc/string/struct.String.html" title="struct alloc::string::String">String</a>&gt;) -&gt; <a class="enum" href="{{channel}}/core/option/enum.Option.html" title="enum core::option::Option">Option</a>&lt;<a class="enum" href="{{channel}}/core/result/enum.Result.html" title="enum core::result::Result">Result</a>&lt;<a class="primitive" href="{{channel}}/std/primitive.unit.html">()</a>, <a class="struct" href="struct.Error.html" title="struct foo::Error">Error</a>&gt;&gt;;

Related discussion:
text: Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
fn lower_pattern_unadjusted(&mut self, pat: &'tcx hir::Pat<'tcx>) -> Pat<'tcx> { let mut ty = self.typeck_results.node_type(pat.hir_id); <del> if let ty::Error(_) = ty.kind { // Avoid ICEs (e.g., #50577 and #50585). return Pat { span: pat.span, ty, kind: Box::new(PatKind::Wild) }; } </del> let kind = match pat.kind { hir::PatKind::Wild => PatKind::Wild,

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --produces an ICE for the code given below. This code should produce an error (the implementation is missing associated items). (UPDATED: Here's MCVE: ) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Error also occurs on beta and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Thanks! Further minimized:
Assigning as and removing .
Don't know the cause yet, but if you remove the keyword or the operator, then you get this error: My hunch is that somehow, lacking those items, the type of is coming up with something that doesn't implement the expected traits -- I would bet that we are getting an , based on some of the output at the end. Perhaps some of the logic in MIR is failing as a result. The actual ICE location though isn't that illuminating:
I did some digging here. The source of the panic is here, during HAIR construction: In this case, the binding below is of the error type (meaning type check for it failed). By replacing the binding with `` we prevent a local from being created for it, which means that when we try to generate code that reads the local we get a panic . I'm not sure what the correct fix is here. Replacing the binding with was done to prevent other ICEs, but we can't generate valid MIR without the local info. More fundamentally: We're building MIR during typeck because this is an async fn. In the past we probably never would have gotten to this stage. Backtrace: <details</details
Code change:
to `int`s, though. We can make it usable by any type, but we haven't quite gotten there yet! <del> You can have any number of values in an enum: </del> <ins> You can also have any number of values in an enum: </ins> ```{rust} enum OptionalColor {

Related discussion:
text: See: The keyword hasn't been introduced until that point but it's used in the code example which is confusing. I believe an if/else solution would be more explanatory, especially because the reader probably wants to see how to unpack the variant of . The same enum could then be used with the keyword in the beginning of the next chapter ().
You are correct. Nice catch!
Are you ok with simply reordering them ? Because introducing sum type without precedent knowledge of pattern matching is a bit pointles (or at least misses the fact that they are juste AWESOME for pattern matching). If you're ok with this I'll PR in a few hours :)
Maybe, if it flows okay, yeah. I do want to put SOME kind of mention of it first.
It's probably easy to find out what is doing by simply looking at it. This part of the tutorial is just a bit confusing and should be fixed. However, my main concern here is that the reader is left clueless on how to solve this problem with if/else: In fact, I really don't know how the equivalent code without would look like. I've briefly tried to figure it out and gave up.
With an Option you coul unwrap I guess. By the way why did you write a fake option enum ? Because that's basically what is done with this, it might be better to give out the real name
Because we haven't talked about generics yet.
Nicely done. However, my other concern, how this example could be done without , remains unresolved. I'm certain that I'm not the only one who wants to know how it works with before continue reading about . Should I open another issue for that matter?
I'm honestly not sure that it is possible with an arbitrary enum... You can test for some arbitrary values but i guess but that's it. Bt it's more an issue of sum types in general rather than a Rust issue (I can't find ways to do that in haskell nor in scala)
Alright, I expected something like this as I was unable to figure out how to write it without . I don't have much experience with statically typed languages, therefore the concept was new to me. If you are right, could we mention in the tutorial that it is actually not possible to write an equivalent solution with ? Certainly, I can't be the only one who was a bit puzzled.
Code change:
to `int`s, though. We can make it usable by any type, but we haven't quite gotten there yet! <del> You can have any number of values in an enum: </del> <ins> You can also have any number of values in an enum: </ins> ```{rust} enum OptionalColor {

Related discussion:
text: Cheers.
Thanks a lot for the remark, it's exactly the kind of comment needed, if you see others don't hesitate to open new issues :) I'll try to add this tonight or tomorrow.
Code change:
// Regression test for issue #4935 fn foo(a: usize) {} <del> fn main() { foo(5, 6) } //~ ERROR this function takes 1 parameter but 2 parameters were supplied //~^ NOTE the following parameter type was expected </del> <ins> fn main() { foo(5, 6) } //~^ ERROR this function takes 1 parameter but 2 parameters were supplied //~| NOTE the following parameter type was expected //~| NOTE expected 1 parameter </ins>

Related discussion:
text: From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.
Code change:
<ins> // check-pass // This is currently stable behavior, which was almost accidentally made an // error in #102161 since there is no test exercising it. I am not sure if // this _should_ be the desired behavior, but at least we should know if it // changes. fn main() {} trait Foo { fn fn_with_type_named_same_as_local_in_param(b: i32, b: i32); } </ins>

Related discussion:
text: Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug
Code change:
<ins> // check-pass // This is currently stable behavior, which was almost accidentally made an // error in #102161 since there is no test exercising it. I am not sure if // this _should_ be the desired behavior, but at least we should know if it // changes. fn main() {} trait Foo { fn fn_with_type_named_same_as_local_in_param(b: i32, b: i32); } </ins>

Related discussion:
text: I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by
Code change:
<ins> error: Unexpected `@` in struct pattern --> $DIR/at-in-struct-patterns.rs:8:15 | LL |     let Foo { var @ field1, .. } = foo; |         ---   ^^^^^ |         | |         while parsing the fields for this pattern | = note: struct patterns use `field: pattern` syntax to bind to fields = help: consider replacing `new_name @ field_name` with `field_name: new_name` if that is what you intended error: `@ ..` is not supported in struct patterns --> $DIR/at-in-struct-patterns.rs:10:26 | LL |     let Foo { field1: _, bar @ .. } = foo; |         ---              ^^^^^^^^ |         | |         while parsing the fields for this pattern | help: bind to each field separately or, if you don't need them, just remove `bar @` | LL -     let Foo { field1: _, bar @ .. } = foo; LL +     let Foo { field1: _, .. } = foo; | error: `@ ..` is not supported in struct patterns --> $DIR/at-in-struct-patterns.rs:11:15 | LL |     let Foo { bar @ .. } = foo; |         ---   ^^^^^^^^ |         | |         while parsing the fields for this pattern | help: bind to each field separately or, if you don't need them, just remove `bar @` | LL -     let Foo { bar @ .. } = foo; LL +     let Foo { .. } = foo; | error: expected identifier, found `@` --> $DIR/at-in-struct-patterns.rs:12:15 | LL |     let Foo { @ } = foo; |         ---   ^ expected identifier |         | |         while parsing the fields for this pattern error: expected identifier, found `@` --> $DIR/at-in-struct-patterns.rs:13:15 | LL |     let Foo { @ .. } = foo; |         ---   ^ expected identifier |         | |         while parsing the fields for this pattern error[E0425]: cannot find value `var` in this scope --> $DIR/at-in-struct-patterns.rs:9:10 | LL |     dbg!(var); |          ^^^ not found in this scope | help: consider importing this function | LL + use std::env::var; | error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim
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. // error-pattern: expected item, found `parse_error` include!("../auxiliary/issue-21146-inc.rs"); fn main() {} </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:
this.pat_bindings(&**pat, |this, ln, var, sp, id| { this.warn_about_unused(sp, id, ln, var); }); <ins> visit::walk_expr(this, expr); </ins> } // no correctness conditions related to liveness

Related discussion:
text: compiles without a peep, even though and are unused. Commenting out the gives the expected output:
I think this an be closed
Thanks (fixed in )