jiebi/CodeConvo huggingface dataset:
Code change:
sess.abort_if_errors(); } <del> // Clean up on Darwin if sess.targ_cfg.os == abi::OsMacos { </del> <ins> // On OSX, debuggers needs this utility to get run to do some munging of the // symbols if sess.targ_cfg.os == abi::OsMacos && sess.opts.debuginfo { </ins> // FIXME (#9639): This needs to handle non-utf8 paths run::process_status("dsymutil", [output.as_str().unwrap().to_owned()]); }

Related discussion:
text: Perhaps there's a minimum amount of debug info we can output by default without breaking things. This is alarming to newcomers.
I am 99% confident this comes straight from dsymutil.
Possibly related to
non-critical for 0.6, de-milestoning
+1 to fix this or provide temporary "fix"
As a new user curious about the language, this definitely made me think I'd done something wrong while building. This issue is also not a top result in Google if you search for the full error message and I haven't seen anywhere else that the issue is detailed. While this is totally understandable in a pre 1.0 release, it would be really nice to have a note that it's expected in the README and/or printed to the console at the end of the build output.
+1 30 seconds into playing with rust, initial impression: 0.6 is still not ready for anything more than casual experimentation. If that's the message you intend to send, well done!
+1 Occurs when building rust, and when compiling .rs files. I was almost certain my build had failed since the last ~6 lines were these warnings (while everything was fine). I also get this warning every time I compile any .rs file.
Nominating, production ready.
accepted for production-ready milestone
Thanks! I know it's a small thing, but I certainly appreciate it :)
I'd be curious what happens if we stop running dsymutil for non-debug builds. In particular, does the gdb experience suffer at all when debugging the resulting binary?
I am writing a rustpkg script for to fix cadencemarseille/rust-pcre and this is tripping me up because part of the script looks at output, which includes this warning in the data. For now I think I'll just use the last line of output, but it would be great to have this issue fixed.
I'm still getting this in Homebrew Rust on Mavericks. Trace: System: When Homebrew gets Rust 0.9 for Mavericks, will this be fixed?
I get this all the time still.
That's probably because we build servo with debug symbols, hence we run dsymutil. I would expect will have a better experience.
The job failed! Check out the build log: <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</details
Code change:
<ins> error[E0478]: lifetime bound not satisfied --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:19:16 | LL |     type Bar = BarImpl<'a, 'b, T>; |                ^^^^^^^^^^^^^^^^^^ | note: lifetime parameter instantiated with the lifetime `'a` as defined here --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:14:6 | LL | impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |      ^^ note: but lifetime parameter must outlive the lifetime `'b` as defined here --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:14:10 | LL | impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |          ^^ error: lifetime may not live long enough --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:23:21 | LL |         self.enter_scope(|ctx| { |                           --- |                           | |                           has type `&'1 mut FooImpl<'_, '_, T>` |                           has type `&mut FooImpl<'2, '_, T>` LL |             BarImpl(ctx); |                     ^^^ this usage requires that `'1` must outlive `'2` error: lifetime may not live long enough --> $DIR/lifetime-not-long-enough-suggestion-regression-test-124563.rs:22:9 | LL |   impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> |        --  -- lifetime `'b` defined here |        | |        lifetime `'a` defined here ... LL | /         self.enter_scope(|ctx| { LL | |             BarImpl(ctx); LL | |         }); | |__________^ argument requires that `'a` must outlive `'b` | = help: consider adding the following bound: `'a: 'b` = note: requirement occurs because of a mutable reference to `FooImpl<'_, '_, T>` = note: mutable references are invariant over their type parameter = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0478`. </ins>

Related discussion:
text: : <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.
Code change:
///     Ok(()) /// } /// ``` <del> #[unstable(feature = "rw_exact_all_at", issue = "51984")] </del> <ins> #[stable(feature = "rw_exact_all_at", since = "1.33.0")] </ins> fn write_all_at(&self, mut buf: &[u8], mut offset: u64) -> io::Result<()> { while !buf.is_empty() { match self.write_at(buf, offset) {

Related discussion:
text: The and traits contain convenience methods and wrapping and . This issue tracks addition of similar methods to trait's and . This is implemented in .
if this is a tracking issue, maybe it should have the label
We should eventually add similar methods to .
I know nothing about developing on Windows so I can't do it myself but I guess a PR would be accepted. Can we stabilize this? Is there anything that still needs to be done?
Seems reasonable to me! fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
What's the next step? Should I make a PR to stabilize? Sorry but I don't fully understand how things work yet.
indeed that should be all that's necessary! If you'd like to make the PR you're also more than welcome to do so!
Code change:
#[macro_use] #[no_link] extern crate macro_reexport_1; //~^ ERROR macros reexports are experimental and possibly buggy <del> //~| HELP add #![feature(macro_reexport)] to the crate attributes to enable </del>

Related discussion:
text: Steps to reproduce: The output of is: does as suggested by the message, but that fails too (as expected): Proposed fix: in the beta and stable channels (i.e. whenever is forbidden), the message that suggests adding should not be shown. (Clean up the test case with .) CC
Gonna milestone this real quick, as it seems quite important.
I might be able to whip up a quick fix, though I'm not 100% sure about testing it properly ... (I've never actually tried building something for a non-dev release channel before...)
after chatting with it seems like I have a patch, building it now
gonna leave to it
Hello good Rust folks :smile: Before the beta, I used which is in . Is there any way to use this trait during the beta ? I'm not sure how I can get the code to compile. Thanks for any tip / hints you can offer :+1:
Hi Commenting on random unrelated issues is usually not the right thing to do. You should rather open a new issue, or ask on . But to answer your question anyway, that trait only has : … and is stable and can be used on beta. So I’d recommend you copy/paste the trait into your code, or make a function.
Thanks for taking the time to answer. I appreciate it. I don't see how this is unrelated. This is related, since the code I'm talking about used to compile with and the compiler suggests to do that, during the beta period. Thanks for your tip on copying the function :+1: I guess I'll just do that if nothing better is available and change this again when the trait is stable.
This specific issue is about fixing one of the compiler’s error message, not about fixing code that triggers that error. It really helps everyone to keep discussions on topic.
Alright. I understand. I'll make sure to open a new issue or go on StackOverflow next time if appropriate. Thanks again :+1:
This doesn't seem to be properly fixed in the beta channel. I'm still being recommended to add in the errors, and then told it's not available in the beta channel. Rust version: The code I used (snappy example in the docs with the extra addition on the first line:
This happened after Beta release.
Code change:
#[macro_use] #[no_link] extern crate macro_reexport_1; //~^ ERROR macros reexports are experimental and possibly buggy <del> //~| HELP add #![feature(macro_reexport)] to the crate attributes to enable </del>

Related discussion:
text: We'll see the effect of this patch in 1.0 and afterwards Beta, etc.
Whoops, I thought this made it in before beta. Thanks!
are there plans to release updates to the beta channel within a given 6 weeks cycle? Either this one or in the future.
I'm certain there will be updates; see discussion from last night here:
So how does one fix this error? I'm a new user of the rust library and I can't seem to use the collections library during the beta due to this problem. Given this git issue is a top google result, it would be nice if there were a solution here. Edit: Looks like the solution is to switch to the rust nightly. Is the entire collections library off-limits in the beta?
by design, you have access to the parts of that are re-exported from (and are stable).
Code change:
base.cpu = "yonah".to_string(); base.max_atomic_width = Some(64); base.pre_link_args.insert(LinkerFlavor::Gcc, vec!["-m32".to_string()]); <del> base.link_env.extend(super::apple_base::macos_link_env("i686")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

Related discussion:
text: <!-- 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. --This used to work on Rust : is present in the framework (on macOS +10.13; on lower versions, in the framework). The framework uses internally, so the symbol is available through that (I think). Linking like this worked previously, but since Rust it started failing. This is . <!-- 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. --OS: macOS Mojave 10.14.6. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sorry if the issue is not very well explained, I'm very inexperienced with how linking works
This is affecting  as well from what I can tell.
This appears to have regressed via , cc As a temporary workaround, you can try setting the environment variable to something like .
With Rust sets to 10.7 for the linker, if not set, to match what we are passing to LLVM. Setting it to 10.8 or above get rids of the linker failure. I will look into this more.
Can you elaborate on that? Building it locally with worked fine for me on an M1.
I can confirm that using gets rid of the linker failure in . For , is required. You need to build a binary, so that the linker is actually invoked. Try building an example (e.g. ).
I can clarify this a little more: If you were building a Rust program for an Apple platform that linked to APIs with availability somewhere between 10.7+ and 12.0+, and you weren't setting your own deployment target, has revealed a bug in your build process. Your binaries were only ever going to run on recent OS releases, but you would have been unaware without testing.
Code change:
base.cpu = "yonah".to_string(); base.max_atomic_width = Some(64); base.pre_link_args.insert(LinkerFlavor::Gcc, vec!["-m32".to_string()]); <del> base.link_env.extend(super::apple_base::macos_link_env("i686")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

Related discussion:
text: For coreaudio, if it really requires APIs from 11.0+, that seems a bit recent/limiting for a library that's existed since forever on macOS. If the authors were unaware of this, has revealed that they need to do more work to attain backwards compatibility. There will be more breakage like it, but it is the good kind, because anyone using newer Apple APIs should be aware of their minimum platform requirement, just as Xcode forces you to be.
Hmm, this change had more impact than I thought. to determine which minimum Macos version to pass as part of the target triple to LLVM and to ld via by looking at the various command line options and environment variables that have accumulated over the years. If nothing is specified, it apparently defaults to the minimum of the specified in the SDKROOTs and the host Macos version . I think ideally we should probably try to mimic this behavior somewhat so we don't confront users with having to set , while they don't have to do it using clang. Not sure how we can easily accomplish this though.
Actually, that makes a lot of sense, thanks! I fully agree that it's better to catch these issues when developing (instead of later, when users complain that the application doesn't work on their older system)! I've opened to fix the linking in , and would fix the linking in .
Note that this is a breaking change for macOS users, before, they didn't have to specify , now they do. Furthermore, they have no easy way to find out that they need to (they just get a confusing linker error)! Additionally, the affected crates (that we know about) are quite widely used (at least half of all Rust games depend on and/or ), and have not yet fixed the issue, nor yet released updated versions which includes these fixes. And even when this has been done, it will take time before users have run and received working versions (can probably be helped along by yanking the affected versions). I don't really know the procedure for this, but I would like to propose reverting (at least from the current beta) to give the affected crates more time to update. Again, I really do agree with the change, I just also want to minimize the breakage macOS users will experience from upgrading Rust.
Code change:
base.cpu = "yonah".to_string(); base.max_atomic_width = Some(64); base.pre_link_args.insert(LinkerFlavor::Gcc, vec!["-m32".to_string()]); <del> base.link_env.extend(super::apple_base::macos_link_env("i686")); </del> base.link_env_remove.extend(super::apple_base::macos_link_env_remove()); // don't use probe-stack=inline-asm until rust#83139 and rust#84667 are resolved base.stack_probes = StackProbeType::Call;

Related discussion:
text: Like I wrote I think ideally we should match clang's behavior and thus fall back to the default of the currently configured Macos SDK. That would mean looking at the property of the in the currently configured SDK. Unfortunately I don't really see a reliable way to do get the path to that without running .
I think we should revert the change until you find a way to do this - it seems to be causing a lot of breakage and my understanding is the goal was just to turn a runtime error into a link time error.
Oh sure. I am not against a revert until that is sorted out. I will open a PR. claim
reopening as this is a beta-regression, and we keep those open until beta fix lands (or we explicitly decline to fix).
Backport merged.
Just for reference, the linking in the noted crates have since been fixed: , ,
I root-caused this a little bit more today, sharing my findings: The problem can be reproduced with and the following file: Weirdly enough, if you remove the linking to , everything links fine. I think this is actually a bug in , it seems like: The linker is reading the symbol tables from and to try to figure out where comes from. When reading , it sees that it has a few "", which includes , which is where the symbol actually comes from (well, nowadays from , but that is re-exported from ). But when reading , it finds the symbol , which is intended to indicate that "when linking on older platforms, use instead" But instead, it ends up making it seem like is actually the real , and does not expose , so the linking fails. Again, I believe this to be a linker bug because the problem does not happen with (try passing ).
Code change:
.push((myname, Some(plain_summary_line(item.doc_value())))); } <del> for (_, items) in &mut map { items.sort(); </del> <ins> if self.shared.sort_modules_alphabetically { for (_, items) in &mut map { items.sort(); } </ins> } map }

Related discussion:
text: Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.
Code change:
.push((myname, Some(plain_summary_line(item.doc_value())))); } <del> for (_, items) in &mut map { items.sort(); </del> <ins> if self.shared.sort_modules_alphabetically { for (_, items) in &mut map { items.sort(); } </ins> } map }

Related discussion:
text: The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !
Code change:
[tlgba]: http://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/ [ro]: http://www.rustaceans.org/ [rctd]: ./src/test/COMPILER_TESTS.md <del> [cheatsheet]: https://buildbot.rust-lang.org/homu/ </del> <ins> [cheatsheet]: https://buildbot2.rust-lang.org/homu/ </ins>

Related discussion:
text: This page isn’t working is currently unable to handle this request. HTTP ERROR 503
The bot got moved at some point; try Are there some docs that need to be updated?
Or how about made 302 redirect to the new target url?
Are there some docs that need to be updated? There are few references to the old address in the rust repo, including (all can be found by searching "buildbot").
Fixed the broken link in so I'm going to remove the issue tag here. It would be nice if there was a or something that was a GitHub Pages site that had an for and whatever else relevant resources for maintaining the queue. It'd be easy to change if the homu link changes again in the future.
I on IRC how to do this awhile ago, and I believe they're still basically applicable today. If anyone would like to help implement this and still has questions please just let me know!
Code change:
<del> Subproject commit 2adc39f27b7fd2d06b3d1d470827928766731a1d </del> <ins> Subproject commit fccb2398248802a268fcda544ff3945247ef2119 </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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! cc the PR reviewer, and nominating for compiler team prioritization.
Code change:
#[link_name = "llvm.sqrt.f32"] fn sqrt(x: f32) -> f32; //~^ ERROR linking to LLVM intrinsics is experimental <del> //~| HELP add #![feature(link_llvm_intrinsics)] to the crate attributes </del> } fn main(){

Related discussion:
text: Steps to reproduce: The output of is: does as suggested by the message, but that fails too (as expected): Proposed fix: in the beta and stable channels (i.e. whenever is forbidden), the message that suggests adding should not be shown. (Clean up the test case with .) CC
Gonna milestone this real quick, as it seems quite important.
I might be able to whip up a quick fix, though I'm not 100% sure about testing it properly ... (I've never actually tried building something for a non-dev release channel before...)
after chatting with it seems like I have a patch, building it now
gonna leave to it
Hello good Rust folks :smile: Before the beta, I used which is in . Is there any way to use this trait during the beta ? I'm not sure how I can get the code to compile. Thanks for any tip / hints you can offer :+1:
Hi Commenting on random unrelated issues is usually not the right thing to do. You should rather open a new issue, or ask on . But to answer your question anyway, that trait only has : … and is stable and can be used on beta. So I’d recommend you copy/paste the trait into your code, or make a function.
Thanks for taking the time to answer. I appreciate it. I don't see how this is unrelated. This is related, since the code I'm talking about used to compile with and the compiler suggests to do that, during the beta period. Thanks for your tip on copying the function :+1: I guess I'll just do that if nothing better is available and change this again when the trait is stable.
This specific issue is about fixing one of the compiler’s error message, not about fixing code that triggers that error. It really helps everyone to keep discussions on topic.
Alright. I understand. I'll make sure to open a new issue or go on StackOverflow next time if appropriate. Thanks again :+1:
This doesn't seem to be properly fixed in the beta channel. I'm still being recommended to add in the errors, and then told it's not available in the beta channel. Rust version: The code I used (snappy example in the docs with the extra addition on the first line:
This happened after Beta release.