jiebi/CodeConvo huggingface dataset:
Change:
RevMoveBuckets { raw: raw_bucket.offset(self.capacity as int), hashes_end: raw_bucket.hash, <del> elems_left: self.size </del> <ins> elems_left: self.size, marker:     marker::ContravariantLifetime, </ins> } } }

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!
Change:
Public items that are not documented can be seen with the built-in `missing_docs` lint. Private items that are not documented can be seen with Clippy's `missing_docs_in_private_items` lint. <ins> ## `-w`/`--output-format`: output format When using [`--show-coverage`](https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--show-coverage-get-statistics-about-code-documentation-coverage), passing `--output-format json` will display the coverage information in JSON format. For example, here is the JSON for a file with one documented item and one undocumented item: ```rust /// This item has documentation pub fn foo() {} pub fn no_documentation() {} ``` ```json {"no_std.rs":{"total":3,"with_docs":1,"total_examples":3,"with_examples":0}} ``` Note that the third item is the crate root, which in this case is undocumented. When not using `--show-coverage`, `--output-format json` emits documentation in the experimental [JSON format](https://github.com/rust-lang/rfcs/pull/2963). `--output-format html` has no effect, and is also accepted on stable toolchains. </ins> ### `--enable-per-target-ignores`: allow `ignore-foo` style filters for doctests Using this flag looks like this:

Discussion:
From So not sure which way seems better? What do you think ?
Yeah I think we should document the new stuff and remove the docs for the deprecated stuff (perhaps mention that these deprecated features exist, but not document them in depth)
I've felt confused about this before: Why do we even let people customize which passes are run? That seems like unnecessary entanglement with rustdoc internals.
Also, there doesn't seem to be a flag. Are you thinking of ? If so, rustdoc says that's deprecated. Edit: It looks like is deprecated as well.
What is "the new stuff"? Do you mean things like ? Other than my confusion about that, I agree with Manish here. I think we should mention the deprecated features, but not document them extensively since they shouldn't be used anyway. If we extensively document deprecated features, we are wasting our time and our readers' time.
Yes. I do think the pass infra should stay mostly internal, with specific options being exposed via specific attributes. How we construct it internally should not be something the user should ever have to care about.
Change:
pub fn check_target_feature_trait_unsafe(tcx: TyCtxt<'_>, id: LocalDefId, attr_span: Span) { if let DefKind::AssocFn = tcx.def_kind(id) { let parent_id = tcx.local_parent(id); <del> if let DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </del> <ins> if let DefKind::Trait | DefKind::Impl { of_trait: true } = tcx.def_kind(parent_id) { </ins> tcx.sess .struct_span_err( attr_span,

Discussion:
The compiler currently allows safe default method implementations to be marked with : which I don't think is allowed in . For reference, is not allowed on trait implementations: From my limited testing, this doesn't seem to be unsound however, as the compiler seems to consider all implementations of as having . cc label T-lang T-compiler C-bug F-targetfeature11 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A good resolution to this would be to move it into a separate feature gate I guess?
claim
Change:
<ins> error: type parameters must be declared prior to const parameters --> $DIR/argument_order.rs:4:28 | LL | struct Bad<const N: usize, T> { |           -----------------^- help: reorder the parameters: lifetimes, then types, then consts: `<T, const N: usize>` warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/argument_order.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default error: aborting due to previous error </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this
Change:
RemainderByZero => write!(f, "calculating the remainder with a divisor of zero"), PointerArithOverflow => write!(f, "overflowing in-bounds pointer arithmetic"), InvalidMeta(msg) => write!(f, "invalid metadata in wide pointer: {}", msg), <del> InvalidDropFn(sig) => write!( </del> <ins> InvalidVtableDropFn(sig) => write!( </ins> f, "invalid drop function signature: got {}, expected exactly one argument which must be a pointer type", sig ), <ins> InvalidVtableSize => { write!(f, "invalid vtable: size is bigger than largest supported object") } InvalidVtableAlignment(msg) => write!(f, "invalid vtable: alignment {}", msg), </ins> UnterminatedCString(p) => write!( f, "reading a null-terminated string starting at {} with no null found before end of allocation",

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
} const FOO: &() = { <del> //~^ ERROR encountered dangling pointer </del> <ins> //~^ ERROR it is undefined behavior to use this value </ins> let y = (); unsafe { Foo { y: &y }.long_live_the_unit } };

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D
Change:
self.try_suggest_return_impl_trait(err, expected, ty, fn_id); return true; } <del> false </del> } <ins> _ => {} </ins> } <ins> false </ins> } /// check whether the return type is a generic type with a trait bound

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest how to specify the return type when a function returns a closure. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Is some thing like this not ok ?
release-assignment
It's ok but I was wondering if it's possible to make the compiler give some form of a suggestion to the user on how to do this. Cause the current diagnostics does not suggest how to fix it.
Change:
#![feature(pointer_methods)] #![feature(inclusive_range_fields)] #![cfg_attr(stage0, feature(generic_param_attrs))] <ins> #![feature(rustc_const_unstable)] </ins> #![cfg_attr(not(test), feature(fn_traits, i128))] #![cfg_attr(test, feature(test))]

Discussion:
It should either elaborate on AssertUnwindSafe or else drop the claim that it will elaborate below.
Change:
// Because searching is incremental by character, only the most // recent search query is added to the browser history. <del> if (browserSupportsHistoryApi()) { const newURL = buildUrl(query.original, filterCrates); if (!history.state && !params.search) { history.pushState(null, "", newURL); } else { history.replaceState(null, "", newURL); } } </del> <ins> updateSearchHistory(buildUrl(query.original, filterCrates)); </ins> showResults( execQuery(query, searchWords, filterCrates, window.currentCrate),

Discussion:
Reproduction: Go to Click the gear next to the search field, enable "Directly go to item in search if there is only one result" Refresh page to ensure it's enabled (was required the first time I tried to reproduce, but seemed to work straight away the second time) Search for You should be taken straight to Press "Back" in your browser I expected this to happen: Go back to Instead, this happened: Goes back to then instantly redirects forward again
Taking a look.
Fixed in
Change:
<ins> // run-pass trait Tracked { #[track_caller] fn handle(&self) { let location = std::panic::Location::caller(); assert_eq!(location.file(), file!()); // we only call this via trait object, so the def site should *always* be returned assert_eq!(location.line(), line!() - 4); assert_eq!(location.column(), 5); } } impl Tracked for () {} impl Tracked for u8 {} fn main() { let tracked: &dyn Tracked = &5u8; tracked.handle(); const TRACKED: &dyn Tracked = &(); TRACKED.handle(); } </ins>

Discussion:
After reducing a from I get a segfault from : This repros for me on my up-to-date checkout as well as for the current beta compiler. I'm not sure whether that makes this a regression from stable to beta, since it's an apparent bug in an API which is first stabilizing in this release. cc
this causes a segfault on stable: results in Luckily is very rarely used
Oof! I'm looking at the existing tests and I realize what we missed. We test direct calls to tracked trait methods and we test indirect calls to tracked trait functions (i.e. no receivers), but we don't test indirect calls of trait methods with receivers.
My immediate suspicion is that trait object vtables aren't going through the reification path we to .
Thanks to for confirming this .
Opened with a fix, thanks again to for help finding the missing call!
Assigning .
Change:
#[doc(cfg(unix))] pub fn replaced_function() {} <ins> /// Some doc with `code`! </ins> pub enum AnEnum { WithVariants { and: usize, sub: usize, variants: usize }, }

Discussion:
Ayu-only. The summary in the search results is now blue, when it used to be white. ! ! Ayu-only. The color of impls in Ayu has changed from white to yellow. This may be intentional, but it looked off when I saw it. Note that this happens for all impls, not just foreign impls. ! ! All themes. Certain auto-trait, foreign, unconditional impls have underlines. ! ! All themes. The phrase next to in the search results is now red in addition to itself being red, whereas used to be gray. ! ! All of the regressions seem to have occurred in beta (1.54.0).
Regression 3 is fixed in
Sending a fix for the three others.
Regressions 1 and 4 are fixed in .
Change:
<ins> error[E0107]: function takes 2 generic arguments but 1 generic argument was supplied --> $DIR/foreign-generic-mismatch.rs:6:31 | LL |     foreign_generic_mismatch::const_arg::<()>(); |                               ^^^^^^^^^   -- supplied 1 generic argument |                               | |                               expected 2 generic arguments | note: function defined here, with 2 generic parameters: `N`, `T` --> $DIR/auxiliary/foreign-generic-mismatch.rs:1:8 | LL | pub fn const_arg<const N: usize, T>() {} |        ^^^^^^^^^ --------------  - help: add missing generic argument | LL |     foreign_generic_mismatch::const_arg::<(), T>(); |                                             +++ error[E0107]: function takes 1 lifetime argument but 2 lifetime arguments were supplied --> $DIR/foreign-generic-mismatch.rs:8:31 | LL |     foreign_generic_mismatch::lt_arg::<'static, 'static>(); |                               ^^^^^^            ------- help: remove this lifetime argument |                               | |                               expected 1 lifetime argument | note: function defined here, with 1 lifetime parameter: `'a` --> $DIR/auxiliary/foreign-generic-mismatch.rs:3:8 | LL | pub fn lt_arg<'a: 'a>() {} |        ^^^^^^ -- error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

Discussion:
<!-- 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. --cc still crashes after <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-67037-pat-tup-scrut-ty-diff-less-fields.rs:19:9 | LL |     let P() = U {}; |         ^^^ expected struct `U`, found struct `P` | = note: expected struct `U` found struct `P<_>` error[E0023]: this pattern has 0 fields, but the corresponding tuple struct has 1 field --> $DIR/issue-67037-pat-tup-scrut-ty-diff-less-fields.rs:19:9 | LL | struct P<T>(T); // 1 type parameter wanted | --------------- tuple struct defined here ... LL |     let P() = U {}; |         ^^^ expected 1 field, found 0 error: aborting due to 2 previous errors Some errors have detailed explanations: E0023, E0308. For more information about an error, try `rustc --explain E0023`. </ins>

Discussion:
Source code:
Please provide the source code needed to reproduce this (or preferably a reduced version of that)
Sourced code provided at the end of the document. I'm willing to provide more info if needed.
Reconstructed from first principles:
The problem occurs here:
triage: has PR. P-high, removing nomination.
Change:
<ins> error: expected one of `(`, `,`, `=`, `{`, or `}`, found `:` --> $DIR/issue-103869.rs:2:8 | LL |     vec: Vec<usize>, |        ^ expected one of `(`, `,`, `=`, `{`, or `}` | = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` error: expected item, found `:` --> $DIR/issue-103869.rs:2:8 | LL |     vec: Vec<usize>, |        ^ expected item error: aborting due to 2 previous errors </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Although I know Enums take to form of: I sometimes find myself accidentally defining them as I would a Struct (): The current output is: This always takes more than a few seconds to parse and then realize my mistake. Is it possible to change this to something like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Do you have any suggestion for how the compiler should distinguish between "trying to write an enum with struct syntax" and "trying to write a struct but used the enum keyword"?
Linking to the topic on internals where some other folks have left suggestions (). Although none of those directly address your question. My gut reaction is to assume that if the "enum" keyword is used that truly was the intention of the developer, but if it wasn't, hopefully some help message like the : Would provide enough information to trigger an "Oh wait did I really want to use an enum here?"
claim
Change:
source shared.sh <del> LLVM=7.0.0 </del> <ins> # Currently these commits are all tip-of-tree as of 2018-12-16, used to pick up # a fix for rust-lang/rust#56849 LLVM=032b00a5404865765cda7db3039f39d54964d8b0 LLD=3e4aa4e8671523321af51449e0569f455ef3ad43 CLANG=a6b9739069763243020f4ea6fe586bc135fde1f9 </ins> mkdir clang cd clang <del> curl https://releases.llvm.org/$LLVM/llvm-$LLVM.src.tar.xz |  xz -d |  tar xf - cd llvm-$LLVM.src </del> <ins> curl -L https://github.com/llvm-mirror/llvm/archive/$LLVM.tar.gz |  tar xzf - --strip-components=1 </ins> mkdir -p tools/clang <del> curl https://releases.llvm.org/$LLVM/cfe-$LLVM.src.tar.xz |  xz -d |  tar xf - -C tools/clang --strip-components=1 </del> <ins> curl -L https://github.com/llvm-mirror/clang/archive/$CLANG.tar.gz |  tar xzf - --strip-components=1 -C tools/clang </ins> mkdir -p tools/lld <ins> curl -L https://github.com/llvm-mirror/lld/archive/$LLD.tar.gz |  tar zxf - --strip-components=1 -C tools/lld </ins> <del> curl https://releases.llvm.org/$LLVM/lld-$LLVM.src.tar.xz |  xz -d |  tar xf - -C tools/lld --strip-components=1 mkdir ../clang-build cd ../clang-build </del> <ins> mkdir clang-build cd clang-build </ins> # For whatever reason the default set of include paths for clang is different # than that of gcc. As a result we need to manually include our sysroot's

Discussion:
This can be reproduced in a centos 5 docker container, such as the one provided by python's pypa: The last command produces the following error: Versions: : : : : crashes with the same output as above
Some bisection reveals that this is a regression from actually, and I suspect the most likely candidate of that rollup is cc As to why these symbols are just now showing up, I'm not sure...
Ok I've confirmed is the cause of this bug. I don't really know how this is showing up though as none of the symbols which use are even referenced from the file: None of those symbols are even used from or LLVM or... anywhere it seems. I have no idea what's putting that into some symbol table that needs to be resolved. This may be some LLD change though because if I disable ThinLTO for LLVM itself then these symbol references seem to go away...
Ok I've bisected this to , which makes sense sort of because that's injecting references to all builtins, even if we're not actually using them. I'll follow up with LLVM later tomorrow
Or actually, I've gone ahead and opened an to get the ball rolling there. This is also a beta regression as well, so I'm retagging as such. I believe the only solution we have for now on this is to turn off ThinLTO, so I'm going to send a PR to do that.
Er turns out this is likely already fixed at , so I can try out building that locally
This seems to have regressed again: https://travis- with this Dockerfile: Relevant excerpt:
Indeed! This should be fixed in