jiebi/CodeConvo huggingface dataset:
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // FIXME(#8767) bad error message; Option is not a module impl<T> Option<T> { //~ERROR found module name used as a type </del> <ins> // ignore-tidy-linelength impl<T> Option<T> { //~ERROR inherent implementations are not allowed for types not defined in the current module. </ins> pub fn foo(&self) { } }

Discussion:
Could this be fixed by "::unwrap" in the file (src/test/compile-fail/trait-or-new-type-) // error-pattern: found value name used as a type impl<TOption<T::unwrap { pub fn foo(&self) { } fn main() { } !
I don't understand your question, and that's not valid syntax. You can only create an impl for a type in the same module.
definitely I'm confused :-P. Im trying to determine how to fix this issue.Has been a while I didnt work with C like language(last 5 years have been working with C# and Java) ;-) If I create my own file (as you did writing the ) and implement the same code, I get the issue. Rust is a compiler, so Im assuming that a compiler file should be fixed in order to avoid the user implement namespace overlapping imports. Is my assumption correct about this problem?
Yes, your assumption is correct. The goal is to provide an error message that makes sense when a program tries to create an impl for a type that is not in scope (ie. does not exist).
The code I provided is a Rust compiler file (which i changed), not a new one. Im trying to understand where in the code can I implement this fix
Find the place that generates the error message, and follow the code backwards until it's clear where you could modify it to produce a better error message for this case.
Someone gave me a good tip on how to debug Rust I will try this. The terminal is quite archaic ;-P
I think point was essentially "grep for the error message, and look at the code there", using a full debugger to find out where it is is probably still quite hard at the moment. In any case, running turns up . So it looks like one could just expand the pattern to cover more cases.
I used Eclipse as explained by Michael and did a search and found that file. Now correct me if I'm wrong but the it seems that there is no "match a_def {" (startting at line 444) for the impl type. I'm going to attempt to add a case and test
in there is an enumeration, I dont see one for 'impl' (such as DefTrait for example) line 226. Isn't suppose to be one?

No, because the name we are creating an impl for is not itself an impl; the compiler seems to think that it is a module instead. Figuring out why this is the case would be a good start.
seems like astriranna solved the issue by adding: ast::DefMod(_) =
I just tested but this does not work for 'impl' (still get the same error message)
Yes, that is not a solution, just a slightly clearer (but still incorrect) error message.
Change:
Registry::new(&all_errors) } <ins> fn get_args() -> Vec<String> { env::args_os().enumerate() .map(|(i, arg)| arg.into_string().unwrap_or_else(|arg| { early_error(ErrorOutputType::default(), &format!("Argument {} is not valid Unicode: {:?}", i, arg)) })) .collect() } </ins> pub fn main() { env_logger::init().unwrap(); <del> let result = run(|| run_compiler(&env::args().collect::<Vec<_>>(), </del> <ins> let result = run(|| run_compiler(&get_args(), </ins> &mut RustcDefaultCalls, None, None));

Discussion:
I was able to perform the commands above successfully with both fish and bash fish bash
I am able to as well. Closing! Thanks for the triage.
Hm I'm actually quite surprised that this works. What versions of the compilers were you using? For me it continues to not work:
Oh this may be a shell thing (I'm using zsh), when running after executing the commands in bash I see: I think that the escape syntax for bash must be different.
I just tried zsh and got your error:
Reproducable in bash (note the ).
It now fails saying, "called on an value". I believe this is simply due to using rather than , so it panics on the non-utf8. You can reproduce this with any bad argument at all, e.g. in bash: Accepting will require changes down through the crate, and I guess all the other users of that should be updated too. I'm interested to try, if this sounds ok...
Change:
compiler: self.compiler, target: self.target, tool: $tool_name, <del> mode: Mode::ToolBootstrap, </del> <ins> mode: if false $(|| $unstable)* { // use in-tree libraries for unstable features Mode::ToolStd } else { Mode::ToolBootstrap }, </ins> path: $path, is_optional_tool: false, source_type: if false $(|| $external)* {

Discussion:
See . Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0. e.g. from : ~ The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once. However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work. cc
Doing things this way (using stage2) would also have ensured that was detected early, and never made it into a release.
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc and though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK).
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing.
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language is a bit technical and I couldn't figure it out.
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version.

I think if we wanted to solve this issue the best way to do it would be to: Require compiles on stable, except for the dependency on the crate Have depend on std/test in-tree binaries, so we always build them (with the stage0 compiler) That way works with rebuild-bootstraping and normal use cases because it's not using anything unstable except libtest, which is built from source to link against and already solves this problem otherwise.
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week.
Same issue with 1.40.0 again, when using itself as stage0: ~ CC AFAICT you do not have a patch that fixes this on Fedora either.
For 1.40.0 the relevant commit to conditionally-apply or not is . For the upcoming 1.41.0 (or is it 1.42.0) stable release it seems we will have to do the same thing for .
Change:
return vec![]; } <del> // Write the colunmn separator. </del> <ins> // Write the column separator. </ins> // // After this we will have: //

Discussion:
In we account for the visible char width when calculating the label and span positions, but we do not do so for the vertical bar tying them together, causing the following output: where it should be (Found during )
I would like to solve this as a first time issue. Best with some pointers where to start :)
the code that draws the vertical lines is at and the one that draws the span labels is right below I think the error might be using instead of , but I'm not entirely certain. If this is your first time compiling , you probably want to read the , but the TL;DR: is "run to build the compiler up to the first stage and update the test output files". You might also want to wait until the linked PR is merged so you have a test case, unless you wish to come up with a new one (look for a test that has multiple labels in the same span and pad the source to the left with unicode chars on non-1 width).
Thank you! I did read the rustc guide, and even compiled it on my own once. But thanks for the direction, and the note to the PR. I'll do my best :wink:
Change:
let inner = if let Some(inner) = self.inner() { inner } else { return }; if inner.weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(inner.weak); </ins> unsafe { Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } } }

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.
Change:
| = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) <del> error: aborting due to 14 previous errors </del> <ins> error: aborting due to 22 previous errors </ins>

Discussion:
Given that there should be a lint that is capable of detecting it (there was a suggestion that should also detect it, but it might make sense to be able to lint it individually too).
So maybe should be a lint group, and include this new lint? I am suggesting that because I think should suffice to trigger the new lint.
I've got the basic lint working now. do you think it's worth adding it as a separate lint, renaming to something else (which I can't think of a name for), and adding them both as lints in an group; or better to just integrate it into the current lint?
I'll defer to for that :D
I am partial towards having a hard error when encountering multiple functions with the same name in a given workspace, . Adding this to might be problematic in the wild. Let's make a PR that rolls it into and see the behavior in the wild with a crater run, but if it causes too much fallout, lets make it an independent lint.
There's other ways of using which create UB than just overriding within a workspace, e.g. the example in While adding a hard error for cases that can be detected would be nice, I don't think it's possible in general.
Removing I-prioritize since this is already tracked at
Is there a tracking issue for additional lints like this to similar "unsafe attributes"? I think that'd be great!
not that I know of but you could open one :)
Done
Change:
fn check_block_post(a: &ast::Block); fn check_stmt(a: &ast::Stmt); fn check_arm(a: &ast::Arm); <del> fn check_pat(a: &ast::Pat, b: &mut bool); // FIXME: &mut bool looks just broken </del> <ins> fn check_pat(a: &ast::Pat); fn check_pat_post(a: &ast::Pat); </ins> fn check_expr(a: &ast::Expr); fn check_expr_post(a: &ast::Expr); fn check_ty(a: &ast::Ty);

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
Everything before the first empty line will be reused to describe the component in searches and module overviews.  For example, the function `std::env::args()` <del> above will be shown on the [`std::env`] module documentation.  It is good </del> <ins> above will be shown on the [`std::env`] module documentation. It is good </ins> practice to keep the summary to one line: concise writing is a goal of good documentation.

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
impl Sealed for ops::RangeInclusive<usize> {} #[stable(feature = "slice_get_slice", since = "1.28.0")] impl Sealed for ops::RangeToInclusive<usize> {} <ins> #[stable(feature = "slice_index_with_ops_bound_pair", since = "1.53.0")] impl Sealed for (ops::Bound<usize>, ops::Bound<usize>) {} </ins> } /// A helper trait used for indexing operations.

Discussion:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)
Change:
[`DummyResult`](../syntax/ext/base/struct.DummyResult.html), so that the compiler can continue and find further errors. <ins> To print syntax fragments for debugging, you can use [`span_note`](../syntax/ext/base/struct.ExtCtxt.html#method.span_note) together with [`syntax::print::pprust::*_to_string`](http://doc.rust-lang.org/syntax/print/pprust/index.html#functions). </ins> The example above produced an integer literal using [`AstBuilder::expr_uint`](../syntax/ext/build/trait.AstBuilder.html#tymethod.expr_uint). As an alternative to the `AstBuilder` trait, `libsyntax` provides a set of

Discussion:
As of the original docs on recursive macros are gone. We should have an example that clearly illustrates the increased power vs. the built-in repetition operator.
Change:
include ../../run-make-fulldeps/tools.mk <del> # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) </del> <ins> # ignore-none no-std is not supported # ignore-nvptx64-nvidia-cuda FIXME: can't find crate for 'std' </ins> # Regression test for issue #83112 # The generated test harness code contains spans with a dummy location,

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.
Change:
//! - [`Once`]: Used for a thread-safe, one-time global initialization routine //! //! - [`OnceLock`]: Used for thread-safe, one-time initialization of a <del> //!   global variable. </del> <ins> //!   variable, with potentially different initializers based on the caller. //! //! - [`LazyLock`]: Used for thread-safe, one-time initialization of a //!   variable, using one nullary initializer function provided at creation. </ins> //! //! - [`RwLock`]: Provides a mutual exclusion mechanism which allows //!   multiple readers at the same time, while allowing only one

Discussion:
These types are now, however, the docs don't properly mention them everywhere yet: lists OnceCell in the overview, but not LazyCell. The docs should also explain when I should use which of these types, as they are superficially pretty similar. lists Once and OnceLock, but not LazyLock. The same point about "when to use which type" applies. (It seems like is basically the same as , but I am not sure.) Cc
thatnks for the PR! The question of Once vs OnceLock seems to remain unresolved though. If Once is to OnceLock what is to Mutex, then it should probably be considered extremely niche as one can't even safely protect any data that way?
Yeah, I do indeed have nothing useful to say about Once, basically, because it doesn't seem very useful except as a raw implementation primitive of OnceLock. I suppose we could add a comment that soft-discourages it?
Yeah I think that would be useful.
Change:
match cmt.cat { mc::cat_rvalue(..) | mc::cat_static_item | <del> mc::cat_copied_upvar(_) => { </del> <ins> mc::cat_copied_upvar(mc::CopiedUpvar { onceness: ast::Many, .. }) => { </ins> None } mc::cat_local(id) | mc::cat_arg(id) | <ins> mc::cat_copied_upvar(mc::CopiedUpvar { upvar_id: id, .. }) | </ins> mc::cat_upvar(ty::UpvarId {var_id: id, ..}, _) => { Some(@LpVar(id)) }

Discussion:
compiles . Runs . Connection refused and segfault.
This is a bug in the treatment of captured variables. The line in question is: This is moving into the loop repeatedly when you should only be allowed to do it once. I think I've seen this bug before, but just in case, cc
thanks I've seen some reports of bugs like this before -- it's clear that we need to revisit the code used to check "once fns" -- it was as a temporary start towards support (under a -Z flag) and then pressed into full service, clearly not quite ready for prime time.
Nominating.
updated title to reflect the real issue at hand.
cc
Assigning 1.0, max(P-backcompat-lang, P-high). Gotta fix. edit: The use of above is sort of a joke: take the max of the two P-tag inputs. (Also, I originally wrote P-backcompat-libs, but I'm pretty sure that was a typo.)
Change:
<del> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // 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. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2013-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> use std::cmp::min; use std::io::{stdout, IoResult};

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK waiting for response OK (MoCo employee) OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
ping
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()