jiebi/CodeConvo huggingface dataset:
Code change:
ifdef TRACE CFG_RUSTC_FLAGS += -Z trace endif <ins> ifdef DISABLE_RPATH # NOTE: make this CFG_RUSTC_FLAGS after stage0 snapshot RUSTFLAGS_STAGE1 += --no-rpath RUSTFLAGS_STAGE2 += --no-rpath RUSTFLAGS_STAGE3 += --no-rpath endif </ins> # The executables crated during this compilation process have no need to include # static copies of libstd and libextra. We also generate dynamic versions of all

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:
use ascii; use borrow::{Cow, ToOwned, Borrow}; use boxed::Box; <del> use clone::Clone; </del> use convert::{Into, From}; use cmp::{PartialEq, Eq, PartialOrd, Ord, Ordering}; use error::Error;

Related discussion:
text: We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.
Code change:
#![feature(rustc_attrs)] fn main() { <del> #![rustc_dummy("hi" , 1 , 2 , 1.012 , pi = 3.14 , bye , name ("John"))] </del> <ins> #![rustc_dummy("hi", 1, 2, 1.012, pi = 3.14, bye, name ("John"))] </ins> #[rustc_dummy = 8] fn f() { } <del> #[rustc_dummy(1 , 2 , 3)] </del> <ins> #[rustc_dummy(1, 2, 3)] </ins> fn g() { } }

Related discussion:
text: proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.
Code change:
!msg.contains("if and else have incompatible types") && !msg.contains("if may be missing an else clause") && !msg.contains("match arms have incompatible types") && <del> !msg.contains("structure constructor specifies a structure of type") { </del> <ins> !msg.contains("structure constructor specifies a structure of type") && !msg.contains("has an incompatible type for trait") { </ins> return None } let first = msg.match_indices("expected").filter(|s| {

Related discussion:
text: The multi-line errors should be extended to include this testcase. missed this because the didn't go through . I tried but that didn't work either. If someone can point me to to where to catch it, I can probably fix this too. cc Code: Error: Change to:
Code change:
match ty.normalized.ty_adt_def() { Some(adt_def) if adt_def.has_ctor() => { let (ctor_kind, ctor_def_id) = adt_def.non_enum_variant().ctor.unwrap(); <ins> // Check the visibility of the ctor. let vis = tcx.visibility(ctor_def_id); if !vis.is_accessible_from(tcx.parent_module(hir_id).to_def_id(), tcx) { tcx.sess .emit_err(CtorIsPrivate { span, def: tcx.def_path_str(adt_def.did()) }); } </ins> let new_res = Res::Def(DefKind::Ctor(CtorOf::Struct, ctor_kind), ctor_def_id); let user_substs = Self::user_substs_for_adt(ty); user_self_ty = user_substs.user_self_ty;

Related discussion:
text: I tried this code: I expected to see this happen: compilation should fail because the trait impl is defined outside of the module for the type but refers to its private field. Instead, this happened: this compiled successfully This reproduces on the playground for stable Rust, version 1.69.0:
Adding a main function and attempting to call the (playground link: ) raises the compilation error: !
This can be reproduced with cross-crate (e.i., any other crate can access the private field). This means that all encapsulations that take advantage of the field being private can be bypassed. (For example, if we change Vec to a tuple struct, the same thing as setlen could be done in safe code by abusing this bug.) label +I-unsound Also, this can be reproduced in all versions where is stable (e.i., 1.32+). It's a matter of how you initialize Foo. If you provide a constructor for Foo, you won't get a compile error:
Just for completeness, turning this into a segfault without external crates/just std:
label A-visibility
this has been unsound ever since in version 1.32
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
<ins> error[E0224]: at least one trait is required for an object type --> $DIR/issue-79467.rs:4:5 | LL |     dyn 'static: 'static + Copy, |     ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0224`. </ins>

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. --code from <!-- 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
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `
Code change:
expr.span); } Err(..) => { <del> rcx.fcx.tcx().sess.span_note(expr.span, "cat_expr_unadjusted Errd during dtor check"); </del> <ins> let tcx = rcx.fcx.tcx(); if tcx.sess.has_errors() { // cannot run dropck; okay b/c in error state anyway. } else { tcx.sess.span_bug(expr.span, "cat_expr_unadjusted Errd"); } </ins> } } }

Related discussion:
text: I tried to get a minimal example, now i just ended up with completely senseless code, that still gives the error. playpen says: if you remove the for loop, only the last two cat_expr notes are left. adding more code just ends up with more of the notes.
this is pretty much my fault. :) In all the cases that I have seen where it arises, it is due to a type error (or a type inference failure at at least) somewhere in the code. Of course the notes are incredibly annoying. I will try to fix.
And of course the concrete example given here is one where there is no type error. At least, not one exposed by compiling this code. (I have not yet managed to show being instantiated concretely without causing some other type error to arise.)
(but there may be a mix of bugs causing the original input here to pass. In particular, the code in the description is doing , but that associated type does not exist. One needs . See also: )
cc
Code change:
#![crate_id="lint_stability#0.1"] #![crate_type = "lib"] <ins> #![feature(macro_rules)] #![macro_escape] </ins> #[deprecated] pub fn deprecated() {} #[deprecated="text"]

Related discussion:
text: The expansion of and both currently cause code to fail the stability check because they expand to reveal unstable implementation details. A seemingly reasonable solution to this would be to just not run the analysis on any code that has been macro-expanded. cc
I definitely agree with this approach: we should be able to annotate a macro with a stability level, and that's what should count for its users. Do we have a way of telling what part of an AST was generated via macro expansion by the time we get to linting?
Mostly; there's the field of a : for normal code, for macro generated code (basically containing the backtrace of macro invocations that led to that point).
OK, that makes this sound like a pretty easy fix. I'll take a quick look at it tomorrow (unless wants to?)
Hm, this seems slightly subtle, since the contents of a macro would then never be checked for stability. This differs to a conventional function, e.g. given , won't warn, but the contents of is still checked, while where is just never checked. (Of course, macros and phasing are both feature gated so you have to opt-in to instability to use non-standard macros anyway.)
Good point. Also, it looks tricky with the current infrastructure to even lint on the macro invocation -- the backtrace of macro expansion does not appear to link to the def_id of the macro (or give any other way of getting at the macro's stability). Nevertheless, I think we should bail out of the lint when we hit the results of expansion; those should be checked, if anywhere, at the site of macro definition. One other question: do syntax extensions also produce the span information you mentioned above? I ask because original problematic cases are written syntax extensions. If not, is there some other way of telling that an expansion happened?
I have a patch ready that bails of out the lint on expanded code. This also seems to mask uses of . If y'all are ok with this strategy for now, I'll file a PR.
Sounds good to me. Thanks!
cc
Code change:
let receiver_ty = sig.inputs()[0]; let receiver_ty = wfcx.normalize(span, None, receiver_ty); <ins> // If the receiver already has errors reported, consider it valid to avoid // unnecessary errors (#58712). if receiver_ty.references_error() { return Ok(()); } </ins> if tcx.features().arbitrary_self_types { if !receiver_is_valid(wfcx, span, receiver_ty, self_ty, true) { // Report error; `arbitrary_self_types` was enabled.

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc
Code change:
let filename = "tests/parser/unclosed-delims/issue_4466.rs"; assert_parser_error(filename); } <ins> #[test] fn crate_parsing_stashed_diag() { // See also https://github.com/rust-lang/rust/issues/121450 let filename = "tests/parser/stashed-diag.rs"; assert_parser_error(filename); } </ins>

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
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.
Code change:
<ins> #![feature(external_doc)] #![crate_name = "foo"] // @has foo/struct.Example.html // @matches - '//pre[@class="rust rust-example-rendered"]'  //     '(?m)let example = Example::new()n    .first()n    .second()n    .build();Z' /// ```rust /// let example = Example::new() ///     .first() #[cfg_attr(not(feature = "one"), doc = "    .second()")] ///     .build(); /// ``` pub struct Example; // @has foo/struct.F.html // @matches - '//pre[@class="rust rust-example-rendered"]'  //     '(?m)let example = Example::new()n    .first()n    .another()n    .build();Z' ///```rust ///let example = Example::new() ///    .first() #[cfg_attr(not(feature = "one"), doc = "    .another()")] ///    .build(); /// ``` pub struct F; // @has foo/struct.G.html // @matches - '//pre[@class="rust rust-example-rendered"]'  //     '(?m)let example = Example::new()n.first()n    .another()n.build();Z' ///```rust ///let example = Example::new() ///.first() #[cfg_attr(not(feature = "one"), doc = "    .another()")] ///.build(); ///``` pub struct G; // @has foo/struct.H.html // @has - '//div[@class="docblock"]/p' 'no whitespace lol' ///no whitespace #[doc = " lol"] pub struct H; // @has foo/struct.I.html // @matches - '//pre[@class="rust rust-example-rendered"]' '(?m)4 whitespaces!Z' ///     4 whitespaces! #[doc = "something"] pub struct I; // @has foo/struct.J.html // @matches - '//div[@class="docblock"]/p' '(?m)anno whitespacenJust some text.Z' ///a ///no whitespace #[doc(include = "unindent.md")] pub struct J; // @has foo/struct.K.html // @matches - '//pre[@class="rust rust-example-rendered"]' '(?m)4 whitespaces!Z' ///a /// ///    4 whitespaces! /// #[doc(include = "unindent.md")] pub struct K; </ins>

Related discussion:
text: There are two relevant passes: runs second and removes leading columns of whitespace from the docs. This runs on a single "doc fragment" at a time, because of merging that normally means the entire documentation string, but since sugared and raw docs aren't merged they remain as separate fragments and use their own widths of leading whitespace to strip.
That also matches up with first released in 1.24 which introduced this distinction between doc kinds in order to fix , which IMO was user error in not matching the indent depth.
Code change:
#![crate_name = "foo"] // @has foo/fn.f.html <del> // @has - '//*[@class="rust fn"]' 'pub fn f(0u8 ...255: u8)' </del> <ins> // @has - '//*[@class="rust fn"]' 'pub fn f(_: u8)' </ins> pub fn f(0u8...255: u8) {}

Related discussion:
text: Rustdoc on [nightly documents][1] methods have signature of as while it only has to document it as . ! On [rustdoc stable][2], things are normal: ! : Version 1.49.0 ( 2020-12-29) [1]: [2]:
I'd like to investigate this :)
searched nightlies: from nightly-2020-12-29 to nightly-2021-01-22 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: This regressed in , so this is probably caused by
This also affects Where will generate:
So a few observations: which displays mutability in patterns, causing to be displayed the mechanism for detecting and eliding works by , but as returns instead of , the comparison fails and displays the type.
I see two path to solving this bug: an option for to not display the mutability in patterns revert cc what do you think?
I would prefer to go for 1, there's no reason to have two completely different functions for pretty-printing.
Assigning and removing as in the prioritization working group.
(now a beta regression)
Code change:
} // Empty groups `a::b::{}` are turned into synthetic `self` imports <del> // `a::b::c::{self as _}`, so that their prefixes are correctly </del> <ins> // `a::b::c::{self as __dummy}`, so that their prefixes are correctly </ins> // resolved and checked for privacy/stability/etc. if items.is_empty() && !empty_for_self(&prefix) { let new_span = prefix[prefix.len() - 1].ident.span;

Related discussion:
text: The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in
Code change:
<ins> // error-pattern: requires `generator` lang_item #![feature(no_core, lang_items, unboxed_closures)] #![no_core] #[lang = "sized"] pub trait Sized { } #[lang = "fn_once"] #[rustc_paren_sugar] pub trait FnOnce<Args> { type Output; extern "rust-call" fn call_once(self, args: Args) -> Self::Output; } pub fn abc() -> impl FnOnce(f32) { |_| {} } fn main() {} </ins>

Related discussion:
text: This somehow doesn't occur when putting the function in a non crate, yet I can't find any difference between the version of and this one. () Errors:
Seems like it panic when the trait is not found: Maybe it can use  instead.
Code change:
"num_cpus", "ordslice", "racer", <del> "rand 0.7.3", </del> <ins> "rand 0.8.4", </ins> "rayon", "regex", "rls-analysis",

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.
Code change:
"num_cpus", "ordslice", "racer", <del> "rand 0.7.3", </del> <ins> "rand 0.8.4", </ins> "rayon", "regex", "rls-analysis",

Related discussion:
text: One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on
Code change:
pub mod c_str; pub mod os; pub mod path; <ins> pub mod path2; </ins> pub mod rand; pub mod run; pub mod sys;

Related discussion:
text: and all interfaces directly with the file-system should probably use rather than trying to coerce to handle these cases. (Similar issue to .)
nominating feature-complete
Accepted for backwards-compatible
My last referenced commit is a month old, but I'm still working on this issue (currently finishing up the support for Windows paths).
The issues here of dealing with filesystems that are not utf8 seem related to , at least tangentially.