jiebi/CodeConvo huggingface dataset:
Code change:
LL | | /// Some docs. LL | | ...  | <del> LL | |     pub fn bar() {} </del> <ins> LL | |     } </ins> LL | | } | |_^ |

Related discussion:
text: The lint seems to be erroneously complaining about missing documentation examples where local types implement foreign traits (both from 3rd party crates and the standard library). The example below should pass all checks as far as I can tell: However, running results in the following warnings: :
cc
I think the current lint behavior is correct. The issue here is on the core lib side. I opened to fix it.
Maybe the lint shouldn't warn when implementing a foreign trait? By the same rationale as
Hmmm... I have shared feelings here: if a trait doesn't provided documentation "by default", doesn't it make sense to complain about it on the implementors?
I guess if you can add docs on the implementation it makes sense - you have a way to fix it.
That's mainly my position yes. :)
Unfortunately, that drags with itself more issues. First of all, I have to implement said examples on all of the implementations I write. Second, I have to copy (and correctly maintain said copy) the original example-less documentation onto every instance so that it's not lost by the language server and/or . While this isn't entirely impossible, it's a huge chore, especially when you implement multiple traits on tens of types at a time. While could get its issues fixed, that hardly helps us with the rest of the crate ecosystem. As of now, I have about 300 warnings, and actually useful information just drowns in that flood.
You can disable the lint on a specific implementation in the worst case. However, the goal is to enforce more documentation through the ecosystem. If users start to complain about it to the crates' maintainers, I'm pretty sure the situation will improve pretty quickly.
I don't really like this approach - it should be fixable by you, not by bugging upstream maintainers. was saying something like that for I think.
You can fix it on your side by adding the examples yourself in your implementation. So on that on point, even if not the best, it's still possible.
I suppose in the worst case, I could fork the upstream project, add examples, and hope that it either gets merged or the developer doesn't cause too many conflicts so I can keep it up-to-date.
Code change:
LL | | /// Some docs. LL | | ...  | <del> LL | |     pub fn bar() {} </del> <ins> LL | |     } </ins> LL | | } | |_^ |

Related discussion:
text: But even then, it takes a lot of back-and-forth, a lot of time and effort on both ends to get from my linter complaining about missing examples to a new crate release that fixes it - even if everything goes quick and smooth. There should at least be a way for me to temporarily ignore warnings coming from (or rather because of) 3rd party and standard library crates, so that - at the minimum - I can fix my own linting issues without having to comb through thousands of lines of all too similar lines of warnings every time I generate documentation for testing purposes.
on the implementation?
Like I said, you can ignore the lint on the implementations, or directly on a module if it only contains such cases. Adding a doesn't seem to be such a burden...
Let it be known that I was today days old when I learned that you can apply to a single block. I suppose that will have to suffice for now.
I strongly feel that we should not warn on foreign trait implementations here. Firstly, as said, a lint should be fixable by you. Yes, you can add examples yourself, but that isn't actually the real fix here in most cases. In most cases trait implementations are lightweight and you rarely document them, so you're not actually giving the user a "fix", you're asking them to do something they don't actually want to shut the lint up. That's not good, that is not the actual fix, the actual fix is asking people to fix it upstream, and we should not lint that downstream. "The lint can be ignored" is not good enough for normal situations -- if it was some weird confluence of situations, then, sure, but a foreign trait impl is an extremely normal thing to do.
Coming back on this after a while and I now agree with this issue: we shouldn't lint on foreign trait implementations. I'll send a fix in the following days.
I just tried locally and it seems like this issue has already been fixed. Closing it then.
we should still test that it behaves properly
I'll send a test if there isn't already one then.
Code change:
<ins> // check-pass // Regression test for issue #55099 // Tests that we don't incorrectly consider a lifetime to part // of the concrete type #![feature(type_alias_impl_trait)] trait Future { } struct AndThen<F>(F); impl<F> Future for AndThen<F> { } struct Foo<'a> { x: &'a mut (), } type F = impl Future; impl<'a> Foo<'a> { fn reply(&mut self) -> F { AndThen(|| ()) } } fn main() {} </ins>

Related discussion:
text: Consider the following code (): This code doesn't compile because that all type parameters are in scope for the concrete type. This get fixed eventually, but for the time being, we can work around it using (rust-lang/rfcs; ): However, this pattern does not compose. This example fails to compile (): with the error I'm not entirely sure why this fails, but it seems like the code should be accepted? /cc
Or a somewhat simpler example with just a single existential ():
Maybe also tag with since it's related to existentials? And possibly (or is this terretority?)
Replacing with compiles fine.
Code change:
<del> Subproject commit 20da8f45c601d0eec8af8c0897abd536ad57951f </del> <ins> Subproject commit 71be6f62fa920c0bd10cdf3a29aeb8c6719a8075 </ins>

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! cc the PR reviewer, and -- nominating for prioritization.
I'll make an update pr once the two prs currently in the clippy ci queue are merged
triage: P-medium. Removing nomination tag.
Code change:
<ins> warning: `extern` block uses type `TransparentCustomZst`, which is not FFI-safe --> $DIR/repr-transparent-issue-87496.rs:8:18 | LL |     fn good17(p: TransparentCustomZst); |                  ^^^^^^^^^^^^^^^^^^^^ not FFI-safe | = note: `#[warn(improper_ctypes)]` on by default = note: this struct contains only zero-sized fields note: the type is defined here --> $DIR/repr-transparent-issue-87496.rs:6:1 | LL | struct TransparentCustomZst(()); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: 1 warning emitted </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
modify labels: regression-from-stable-to-nightly Regressed in cc
Hmm, I don't think this is actually a regression. The MCVE triggers an error on stable and beta: and it seems like the requirements for were relaxed by such that this code should compile successfully on nightly.
Sorry, I forgot to re-check this issue before opening my PR. You can have a look at to avoid duplicate work, if it's not too late already...
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Code change:
| NonMutatingUseContext::Copy | NonMutatingUseContext::Inspect | NonMutatingUseContext::Move <ins> | NonMutatingUseContext::PlaceMention </ins> | NonMutatingUseContext::ShallowBorrow | NonMutatingUseContext::SharedBorrow | NonMutatingUseContext::UniqueBorrow,

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. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code change:
// Check whether a span corresponding to a range expression is a // range literal, rather than an explicit struct or `new()` call. fn is_lit(sm: &SourceMap, span: &Span) -> bool { <del> let end_point = sm.end_point(*span); if let Ok(end_string) = sm.span_to_snippet(end_point) { !(end_string.ends_with('}') || end_string.ends_with(')')) } else { false } </del> <ins> sm.span_to_snippet(*span).map(|range_src| range_src.contains("..")).unwrap_or(false) </ins> }; match expr.kind {

Related discussion:
text: Hi there! With this code (here's a ) The compiler reports this error message with a hint but the hint is incorrect due to missing parantheses in this case. The correct answer would be It works correctly when the second line in main is executed, where the range is provided directly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
// @has blanket_with_local.json "$.index[*][?(@.name=='Load')]" pub trait Load { <ins> // @has - "$.index[*][?(@.name=='load')]" </ins> fn load() {} <ins> // @has - "$.index[*][?(@.name=='write')]" fn write(self) {} </ins> } impl<P> Load for P { fn load() {} <ins> fn write(self) {} </ins> } // @has - "$.index[*][?(@.name=='Wrapper')]"

Related discussion:
text: Interesingly, and shockingly If you remove and , this doesn't panic. <details<summaryWhats up with the diff? </summaryThe assetion format is differnt to usual as I've patch rustc with to make it readable, but this can also be repoduced with the latest nightly </details modify labels: +A-rustdoc-json +T-rustdoc
MCVE: One has while the other has - I bet one is going through HIR and the other is going through metadata, that could explain why the generic parameter matters.
I have a similar MCVE generated from , but the only item that differs in the assertion is the visibility: The left has a visibility of , and the right has a visibility of . A similar MCVE, with as a parameter, has as an input for the right side, but not for the left (and the / visibility issue):
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub fn main() { let command = "a"; match command { "foo" => println!("foo"), _     => println!("{}", command), } } </ins>

Related discussion:
text: Hi, The rust optimiser or some other component is not behaving correctly resulting in wrong results. I have produced a small example here : This was reproduced on Mac yosemite: cargo 0.0.1-pre-nightly ( 2015-01-30 02:47:30 +0000) rustc 1.0.0-nightly ( 2015-02-03 14:56:32 +0000) and centos7 x64, rustc 1.0.0-nightly ( 2015-02-05 23:14:28 +0000) Please let me know if you need any more details.
Reduced test case: This segfaults with = 2 (on Linux x86-64, )
This goes back to at least 0.12 - though it prints garbage values instead of segfaulting. 0.11 seems unaffected.
I've done some hacky . I'm not seeing the original data in the IR. cc Is this another memcpy metadata bug? Or a lifetime intrinsic issue. EDIT: turns out , which is used here, calls on its arguments, as if it was certain they were temporaries that didn't outlive the call (which is wrong, in this case). Not sure if needs to create a temporary for the value it's trying to compare with a constant, or the lifetime intrinsic calls shouldn't be emitted for .
This has two parts. When I extended rustc to emit lifetime intrinsics, I chose to put a call to at the end of functions to mark arguments as dead that are passed by value on the stack. This allows LLVM to remove dead stores at the end of functions that it normally can't remove. This works because normally, the caller makes a copy of the value it passes in. Now, the call that match generates to compare the strings is to , which accepts two slices by-value, and slices are large enough to be passed on the stack. Thus, calls to are emitted. But, the call the match generates does not actually make copies of the slices, but passes in pointers to the original slices. That means that the call marks the original alloca as dead, and then things fall apart. Question: Do we want to drop the call for by-value on-stack arguments, or fix the call to eqslice to make copies? cc
just-a-bug; P-high, not 1.0 milestone.
Code change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type = "lib"] #[macro_export] macro_rules! declare { () => ( pub fn aaa() {} pub mod bbb { use super::aaa; pub fn ccc() { aaa(); } } ) } </ins>

Related discussion:
text: Macro definitions encoded to the metadata do not preserve the identifier style, thus certain paths break down.
Nice catch. I was afraid something like this would happen... Really a bug in pretty printing, as it doesn't preserve the ident style. This is what we get for hacking contextual lexer information into the token stream...
The original example now compiles fine, but then I'm not sure about tomaka/android-rs-glue. is this issue still relevant?
I didn't test myself, but reported that it's fixed.
Yeah it looks like this has been fixed, yay!
Code change:
} else if #[cfg(target_os = "hermit")] { #[path = "hermit.rs"] mod real_imp; <del> } else if #[cfg(all(target_env = "msvc", target_arch = "aarch64"))] { #[path = "dummy.rs"] mod real_imp; </del> } else if #[cfg(target_env = "msvc")] { #[path = "seh.rs"] mod real_imp;

Related discussion:
text: The and targets force panic=abort. said : This looks related to , which points at these now-merged LLVM changes: It's possible that we do not need to force panic=abort anymore for arm64 Windows as a result. What's the best way to determine if this is still required?
Theoretically the way to fix this issue is: First Next, run the build Finally, run the tests If that all passes, then the change can land! The tests may be able to be skipped, and some tests may fail, so it may be possible to switch the defaults and we can fixup bugs later. I don't personally have hardware to test these changes on myself, though.
I occasionally have access to a Windows arm64 laptop, so I'll try and get a rustc build going on it at some point.
Code change:
documentation: ~~~ <del> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk.png", </del> <ins> #[doc(html_logo_url = "http://www.rust-lang.org/logos/rust-logo-128x128-blk-v2.png", </ins> html_favicon_url = "http://www.rust-lang.org/favicon.ico", html_root_url = "http://static.rust-lang.org/doc/master")]; ~~~

Related discussion:
text: It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.
Code change:
<ins> error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:3:1 | LL | #[rustc_layout_scalar_valid_range_start(u32::MAX)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:6:1 | LL | #[rustc_layout_scalar_valid_range_end(1, 2)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:9:1 | LL | #[rustc_layout_scalar_valid_range_end(a = "a")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: attribute should be applied to a struct --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:12:1 | LL |   #[rustc_layout_scalar_valid_range_end(1)] |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | / enum E { LL | |     X = 1, LL | |     Y = 14, LL | | } | |_- not a struct error: aborting due to 4 previous errors </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
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).
Code change:
<ins> error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:3:1 | LL | #[rustc_layout_scalar_valid_range_start(u32::MAX)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:6:1 | LL | #[rustc_layout_scalar_valid_range_end(1, 2)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: expected exactly one integer literal argument --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:9:1 | LL | #[rustc_layout_scalar_valid_range_end(a = "a")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: attribute should be applied to a struct --> $DIR/invalid_rustc_layout_scalar_valid_range.rs:12:1 | LL |   #[rustc_layout_scalar_valid_range_end(1)] |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | / enum E { LL | |     X = 1, LL | |     Y = 14, LL | | } | |_- not a struct error: aborting due to 4 previous errors </ins>

Related discussion:
text: Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.
Code change:
pub(super) node_to_hir_id: IndexVec<ast::NodeId, hir::HirId>, macro_def_scopes: FxHashMap<Mark, DefId>, expansions: FxHashMap<DefIndex, Mark>, <del> keys_created: FxHashSet<DefKey>, </del> <ins> next_disambiguator: FxHashMap<(DefIndex, DefPathData), u32>, </ins> } // Unfortunately we have to provide a manual impl of Clone because of the

Related discussion:
text: In investigating I was generating some source code, and using the shell script listed in we can see: That's a lot of time to expand a crate that doesn't have any macros in it!
cc you may be interested in this!
A looks like almost all the time is spent in In which case, cc
Apparently most time is spent
called ~38k times
Since we need to build the module graph and resolve imports during expansion for macros 2.0, we must construct node ids and def ids throughout expansion (i.e. interleaved arbitrarily many times until we hit fix-point). Ideally we'd keep running totals of the time spent assigning node ids, assigning def ids, etc. for more accurate profiling information within the expansion step.
in theory though isn't the fixed point for this crate the crate itself? (e.g. there's no macros here). Or are the def ids persisted for the rest of compilation, so "blaming" expansion isn't quite correct here?
Yeah, the def ids are persisted for the rest of compilation. We could move the "first round" of def id collection (in which we collect the raw, unexpanded source) outside of expansion, but that would introduce more code complexity and wouldn't count the time we spend collecting def ids for AST that comes from macro expansions.
Ah ok, nah it seems fine! I think there's a number of cases where is attributing time in the wrong place nowadays... Still it seems odd that 30-50k invocations of this function would take so long to execute?
Do I understand this correctly that all DefIds generated are actually used, right? There are no "temporary" DefIds? Each of these invocations creates a Blake2 hasher. I'd be interested how the performance looks with other hashing algorithms. I'd like to switch to something faster anyway:
Are you sure this isn't the other quadratic case fixed in ?
It may very well be! Feel free to close this w/ that PR landing, I'll verify to be sure but I'd imagine you're correct in that it's fixed by
er, didn't mean to close just yet