jiebi/CodeConvo huggingface dataset:
Change:
} }; <del> match parser.parse_mod(&token::Eof) { Ok((_attrs, items, _span)) => { for item in items { </del> <ins> loop { match parser.parse_item(ForceCollect::No) { Ok(Some(item)) => { </ins> if !found_main { if let ast::ItemKind::Fn(..) = item.kind { if item.ident.name == sym::main {

Discussion:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.
Change:
<ins> #![feature(generic_associated_types)] #![allow(unused)] trait Trait<'a> { type Foo; type Bar<'b> //~^ NOTE associated type defined here, with 1 lifetime parameter //~| NOTE where Self: 'b; } struct Impl<'a>(&'a ()); impl<'a> Trait<'a> for Impl<'a> { type Foo = &'a (); type Bar<'b> = &'b (); } type A<'a> = Impl<'a>; type B<'a> = <A<'a> as Trait>::Foo; //~^ ERROR missing lifetime specifier //~| NOTE expected named lifetime parameter type C<'a, 'b> = <A<'a> as Trait>::Bar; //~^ ERROR missing lifetime specifier //~| ERROR missing generics for associated type //~| NOTE expected named lifetime parameter //~| NOTE these named lifetimes are available to use //~| NOTE expected 1 lifetime argument fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: () I expected to see this happen (which works correctly with rustc 1.57.0 stable): But with , I get: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Also consider the following code, which creates an error message that could be more precise. I wouldn't call the following example a bug, but maybe these two issues are related: () Error output:
I think this is due to cc: let me see if I can fix this real quick.
claim
label +regression-from-stable-to-nightly +A-diagnostics
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
<ins> // #106728 fn main() { for i in 0.2 { //~^ ERROR `{float}` is not an iterator //~| `{float}` is not an iterator //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE in this expansion of desugaring of `for` loop //~| NOTE if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` //~| NOTE required for `{float}` to implement `IntoIterator` println!(); } } </ins>

Discussion:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?
Change:
The signature of `overwrite` is clearly valid: it takes mutable references to two values of the same type, and overwrites one with the other. If `&mut T` was <del> variant over T, then `&mut &'a str` would be a subtype of `&mut &'static str`, since `&'a str` is a subtype of `&'static str`. Therefore the lifetime of </del> <ins> variant over T, then `&mut &'static str` would be a subtype of `&mut &'a str`, since `&'static str` is a subtype of `&'a str`. Therefore the lifetime of </ins> `forever_str` would successfully be "shrunk" down to the shorter lifetime of `string`, and `overwrite` would be called successfully. `string` would subsequently be dropped, and `forever_str` would point to freed memory when we

Discussion:
The exact opposite is said at the beginning of the chapter : Also, the doc seems to be meant for the Randolf-Carters of this world or the others, and while it is nice to introduce the more abstract notion of subtyping early on, it would be much more readable if "is a subtype of" were replaced with "outlives" in the later explanations IMHO.
Oops! Good catch.
we should discuss tagging for the nomicon, for now, tagging with docs and assigning to you
Change:
if sess.targ_cfg.os == abi::OsMacos { cmd.args(["-dynamiclib", "-Wl,-dylib"]); <del> if !sess.opts.cg.no_rpath { </del> <ins> if sess.opts.cg.rpath { </ins> let mut v = Vec::from_slice("-Wl,-install_name,@rpath/".as_bytes()); v.push_all(out_filename.filename().unwrap()); cmd.arg(v.as_slice());

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
config.llvm_assertions = llvm_assertions.unwrap_or(false); config.llvm_tests = llvm_tests.unwrap_or(false); config.llvm_plugins = llvm_plugins.unwrap_or(false); <del> config.rust_optimize = optimize.unwrap_or(true); </del> <ins> config.rust_optimize = optimize.unwrap_or(RustOptimize::Bool(true)); </ins> let default = debug == Some(true); config.rust_debug_assertions = debug_assertions.unwrap_or(default);

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
> ***Note:*** Trait inheritance does not actually work with objects yet <ins> ## Deriving implementations for traits A small number of traits in `core` and `std` can have implementations that can be automatically derived. These instances are specified by placing the `deriving` attribute on a data type declaration. For example, the following will mean that `Circle` has an implementation for `Eq` and can be used with the equality operators, and that a value of type `ABC` can be randomly generated and converted to a string: ~~~ #[deriving(Eq)] struct Circle { radius: float } #[deriving(Rand, ToStr)] enum ABC { A, B, C } ~~~ The full list of derivable traits is `Eq`, `TotalEq`, `Ord`, `TotalOrd`, `Encodable` `Decodable`, `Clone`, `IterBytes`, `Rand` and `ToStr`. </ins> # Modules and crates The Rust namespace is arranged in a hierarchy of modules. Each source

Discussion:
As far as i see it, "deriving" is documented neither in the tutorial nor in the manual. Example:
Change:
/// element of this slice: /// /// ``` <del> /// #![feature(slice_ptr_range)] /// </del> /// let a = [1, 2, 3]; /// let x = &a[1] as *const _; /// let y = &5 as *const _;

Discussion:
Tracking issue for by See
Anything holding up stabilization on this? I'd like to be able to use this to check if two slices overlap, as pointers implement . It seems like a simple API that doesn't have a ton of complexity to it.
Note that with these functions can be made . The stabilization of these methods as can just be tracked as part of .
Thanks! PR: .
Change:
test::Clippy, test::RustDemangler, test::CompiletestTest, <ins> test::CrateRunMakeSupport, </ins> test::RustdocJSStd, test::RustdocJSNotStd, test::RustdocGUI,

Discussion:
The library is currently not registered/configured in bootstrap to be able to run its unit tests via . See for an example on how compiletest unit tests are ran. I plan to get to this eventually (busy ATM), but if someone wants to try implementing this feel free to claim it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks, I'm doing this. claim
Change:
<ins> // check-pass #![allow(opaque_hidden_inferred_bound)] #![allow(dead_code)] trait Duh {} impl Duh for i32 {} trait Trait { type Assoc: Duh; } impl<R: Duh, F: FnMut() -> R> Trait for F { type Assoc = R; } fn foo() -> impl Trait<Assoc = impl Send> { || 42 } fn main() {} </ins>

Discussion:
Note: Switching back to 1.65 compiles fine : </p</details
label +E-needs-mcve
Sorry for the noise on this issue, but I just realized what I had done which apparently got around this issue. I fixed a new warning in my web server library by turning this.. into this
I caused this. Let me put up a fix.
Change:
LL |     let _: S::C; |            ^^^^ help: use fully-qualified syntax: `<S as Trait>::C` <del> error: associated type `A` is private </del> <ins> error[E0624]: associated type `A` is private </ins> --> $DIR/item-privacy.rs:119:12 | <ins> LL |         type A = u8; |         ------ associated type defined here ... </ins> LL |     let _: T::A; |            ^^^^ private associated type

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
from rust_types import * <del> rust_enabled = 'set language rust' in gdb.execute('complete set language ru', to_string=True) </del> _gdb_version_matched = re.search('([0-9]+).([0-9]+)', gdb.VERSION) gdb_version = [int(num) for num in _gdb_version_matched.groups()] if _gdb_version_matched else []

Discussion:
Currently, support for pretty-printing slice types is missing for rust-gdb.
Can you describe in more detail?
provides pretty-printing function for some Rust types, such as , , , etc. This allows gdb to display values of some types in a more readable way. I think it is implemented in the following files: , , Currently, slices can only be displayed as a pointer and a length value in the debugger. I hope rust-gdb can support displaying slices. I also noticed that already supports pretty-printing const slices (), but not mutable slices (). Maybe rust-lldb can also add pretty-printing support fur mutable slices.
label A-slice C-enhancement T-dev-tools
Change:
let is_syntactic_ambiguity = !has_sub && bm == BindingMode::ByValue(Mutability::Not); match res { <del> Res::Def(DefKind::Ctor(_, CtorKind::Const), _) | Res::Def(DefKind::Const, _) | Res::Def(DefKind::ConstParam, _) if is_syntactic_ambiguity => { </del> <ins> Res::SelfCtor(_) // See #70549. | Res::Def( DefKind::Ctor(_, CtorKind::Const) | DefKind::Const | DefKind::ConstParam, _, ) if is_syntactic_ambiguity => { </ins> // Disambiguate in favor of a unit struct/variant or constant pattern. if let Some(binding) = binding { self.r.record_use(ident, ValueNS, binding, false); } Some(res) } <del> Res::Def(DefKind::Ctor(..), _) | Res::Def(DefKind::Const, _) | Res::Def(DefKind::Static, _) => { </del> <ins> Res::Def(DefKind::Ctor(..) | DefKind::Const | DefKind::Static, _) => { </ins> // This is unambiguously a fresh binding, either syntactically // (e.g., `IDENT @ PAT` or `ref IDENT`) or because `IDENT` resolves // to something unusable as a pattern (e.g., constructor function),

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on nightly but not on beta or stable.
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
looks like the probable culprit. cc
Will fix.
Was already looking at this hehe, I have a fix for you in
Change:
"itertools", "jobserver", "libc", <del> "object 0.28.4", </del> <ins> "object 0.29.0", </ins> "pathdiff", "regex", "rustc_apfloat",

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
<ins> error: expected one of `!`, `(`, `+`, `::`, `<`, `>`, or `as`, found `{` --> $DIR/eq-less-to-less-eq.rs:4:15 | LL |     if a =< b { |          --   ^ expected one of 7 possible tokens |          | |          help: did you mean: `<=` error: expected one of `!`, `(`, `+`, `::`, `<`, `>`, or `as`, found `{` --> $DIR/eq-less-to-less-eq.rs:12:15 | LL |     if a = <b { |               ^ expected one of 7 possible tokens error: expected one of `!`, `(`, `+`, `::`, `<`, `>`, or `as`, found `{` --> $DIR/eq-less-to-less-eq.rs:20:16 | LL |     if a = < b { |                ^ expected one of 7 possible tokens error[E0308]: mismatched types --> $DIR/eq-less-to-less-eq.rs:28:8 | LL |     if a =< i32>::abs(-4) { |        ^^^^^^^^^^^^^^^^^^ expected `bool`, found `()` | help: you might have meant to compare for equality | LL |     if a ==< i32>::abs(-4) { |           + error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
The simplest reproduction would be something like this: the `note points at the operator A new user might get confused about needing a type, as the error points at the number instead of the comparator. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error[E0308]: mismatched types --> $DIR/field-access.rs:20:12 | LL |     Fst, |     --- unit variant defined here ... LL |     if let B::Fst = a {}; |            ^^^^^^   - this expression has type `A` |            | |            expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     if let B::Fst = a.b {}; |                     ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:25:9 | LL |     Fst, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Fst => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:26:9 | LL |     Snd, |     --- unit variant defined here ... LL |     match a { |           - this expression has type `A` ... LL |         B::Snd => (), |         ^^^^^^ expected struct `A`, found enum `B` | help: you might have meant to use field `b` of type `B` | LL |     match a.b { |           ^^^ error[E0308]: mismatched types --> $DIR/field-access.rs:32:9 | LL |     match foo { |           --- this expression has type `Foo` LL | LL |         1u32 => (), |         ^^^^ expected union `Foo`, found `u32` | help: you might have meant to use field `bar` of type `u32` | LL |     match unsafe { foo.bar } { |           ^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
sys.exit(err) <del> def require(cmd, exit=True): </del> <ins> def require(cmd, exit=True, exception=False): </ins> '''Run a command, returning its output. On error, <del> If `exit` is `True`, exit the process. Otherwise, return None.''' </del> <ins> If `exception` is `True`, raise the error Otherwise If `exit` is `True`, exit the process Else return None.''' </ins> try: return subprocess.check_output(cmd).strip() except (subprocess.CalledProcessError, OSError) as exc: <del> if not exit: return None print("error: unable to run `{}`: {}".format(' '.join(cmd), exc)) print("Please make sure it's installed and in the path.") sys.exit(1) </del> <ins> if exception: raise elif exit: print("error: unable to run `{}`: {}".format(' '.join(cmd), exc)) print("Please make sure it's installed and in the path.") sys.exit(1) return None </ins> def format_build_time(duration):

Discussion:
I just cloned this rust repo and attemped to build it by calling It initialized submodules, started downloading and failed repeatedly: Waiting longer causes messages above to repeat. It's not connection issue, because it always fails after ~30 seconds of downloading (Messages above repeat in ~2 minutes). I also tried changing to here: What caused download to succeed in a few (1-2) minutes. So I assume it's to blame. version:
I got x.py to test libcore once, but after I updated my local clone of rust, I started getting this repeatedly:
I am nuking my entire rust clone in case changes to the bootstrap are incompatible to previous artifacts produced by previous versions. Why does x.py need to download submodules like and if I am only trying to test ? edit: apparently, this is expected
Nope, I am still getting the DownloadFile exception after refreshing everything, including updating MSYS2 to get curl to 7.65.1, trying the MSYS2 that comes along with git, and messing with
your issue is different and there is no involved (it downloads file through PowerShell). You can see this MSYS2 patch how to make it use instead:
Thank you, it works now
original issue (from comment 0) is not resolved. reported another issue that isn't solved either, there is only workaround available.
We should probably fallback to trying curl if the powershell invocation fails. Reopening. I think a PR would work best here.
For some reason, the powershell download is working again on both my MSYS2 install and from git bash. We still want that fallback though. I couldn't PR a fix though, because I don't know how the exception handling is working in that Python script.
Actually, since I should learn Python anyway, should I PR a fix? Is it as simple as detecting an exception occurred and refactoring the if-else statement in a way that it would also run ?
That's what I would suggest -- we can make it pretty simple and if anything goes wrong with the powershell call then fallback to curl
It might also make sense to try curl before using powershell, as suggested by in label: +E-easy