jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: variable does not need to be mutable --> $DIR/issue-61424.rs:4:9 | LL |     let mut x; |         ----^ |         | |         help: remove this `mut` | note: lint level defined here --> $DIR/issue-61424.rs:1:9 | LL | #![deny(unused_mut)] |         ^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
(sorry if this is an duplicate or the wrong repo :innocent: ) () Current behavior: no warning Expected behavior: The variable clearly doesn't need to be mutable, still, nothing is detected and no warning is emitted. Rust 1.35.0 (Using the , also in ())
The warning appears again if you switch to 2015 edition. Huh. Nice catch!
I found that Stable 2015 edition produces the warning and everything else doesn't.
cc (likely caused by NLL migrate mode, which was enabled in for the 2015 edition)
Yes, looks like another nll bug. If someone wants to have a go at this, the issue is that we are treating DropAndReplace differently to Assign for the purposes of this lint.
I can try doing it I just don't know here to begin.
I don't know this code too well, but take a look at . The first thing I'd try is adding a case for to the match in that mirrors what's done for .
Makes sense thank you. I was looking at librustc_lint and couldn't find anything.
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. // ignore-tidy-linelength use std::ops::Add; fn main() { let x = &10 as //~^ ERROR the value of the associated type `Output` (from the trait `core::ops::Add`) must be specified &Add; //~^ ERROR the type parameter `RHS` must be explicitly specified in an object type because its default value `Self` references the type `Self` } </ins>

Discussion:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!
Change:
Some(&LOCAL_CRATE) => { let len = CURRENT_LOCATION_KEY.with(|s| s.borrow().len()); let len = if len == 0 {0} else {len - 1}; <del> try!(write!(f, "<a href='{}primitive.{}.html'>", </del> <ins> try!(write!(f, "<a class='primitive' href='{}primitive.{}.html'>", </ins> repeat("../").take(len).collect::<String>(), prim.to_url_str())); needs_termination = true;

Discussion:
links should have colors to highlight that they are links: ! Some find it difficult to know which items are links. [EDIT] Removed sidebar circles. Never thought they needed changing.
has the same issue: ! [EDIT] Removed sidebar circles. Never thought they needed changing.
Totally agree. Also, instead of colors, we could use dashed underlines to indicate links while still keeping the same feel. (I disagree about the sidebar as well, I think its normal to expect those to be links, because they're in a sidebar without any text)
Sidebar is fine, thats a pretty normal convention to have those as links. At first glance I didn't realize most of the text in the main doc area was clickable however, I really like the idea of having the dashed underlines. +1
Didn't think sidebar necessarily should change. Was just highlighting black links. Edited pictures to removed sidebar circles.
Really quick mockup:  It doesn't show in the screenshot, but the last bool has the mouse over it, so it's darker.
code is and maybe some sort of style so it doesn't show up on the [src] link
CC: Don't have a branch but this is probably a straightforward fix if you decide on a style. Or if you like nightpool's suggestion.
I like that style, I think. I am bad at looks, though.
If there are any other decent styles worth pursuing (different brown variant, solid underline, combo, red...I'm just guess here), a quick mockup of them would allow easy compare and contrast. It would allow an easier/faster decision.
+1 from me
I'm currently playing with rustdoc. I may try to implement this once the docs are built.
Change:
/// Region checking during the WF phase for items. `wf_tys` are the /// types from which we should derive implied bounds, if any. <ins> #[instrument(level = "debug", skip(self))] </ins> pub fn regionck_item(&self, item_id: hir::HirId, span: Span, wf_tys: FxHashSet<Ty<'tcx>>) { <del> debug!("regionck_item(item.id={:?}, wf_tys={:?})", item_id, wf_tys); </del> let subject = self.tcx.hir().local_def_id(item_id); let mut rcx = RegionCtxt::new(self, item_id, Subject(subject), self.param_env); rcx.outlives_environment.add_implied_bounds(self, wf_tys, item_id, span);

Discussion:
() I would’ve expected rustc to complain about the not matching the with a suggestion to turn it into . modify labels: A-typesystem, A-lifetimes, A-traits, A-impl-trait, F-typealiasimpl_trait, T-compiler, requires-nightly and someone please add “I-unsound ” (and/or tell me if there is a way to do it myself).
One thing that is of note here is that we properly enforce type bounds, but not lifetime bounds, as the equivalent program with types fails to compile right where we expect that:
Aha! If we change to have an explicit bound, then we get the right error: so we're just missing a check of the implied bounds on the impl
Change:
let [name] = this.check_shim(abi, Abi::C { unwind: false }, link_name, args)?; let thread = this.pthread_self()?; let max_len = this.eval_libc("MAXTHREADNAMESIZE")?.to_machine_usize(this)?; <del> this.pthread_setname_np( </del> <ins> let res = this.pthread_setname_np( </ins> thread, this.read_scalar(name)?, max_len.try_into().unwrap(), )?; <ins> // Contrary to the manpage, `pthread_setname_np` on macOS still // returns an integer indicating success. this.write_scalar(res, dest)?; </ins> } "pthread_getname_np" => { let [thread, name, len] =

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
/// Returns `true` if there was an error forcing the coercion to the `()` type. pub(super) fn if_fallback_coercion<T>( &self, <del> span: Span, </del> <ins> if_span: Span, cond_expr: &'tcx hir::Expr<'tcx>, </ins> then_expr: &'tcx hir::Expr<'tcx>, coercion: &mut CoerceMany<'tcx, '_, T>, ) -> bool

Discussion:
The following code () gives the following error: which is weird, since the clause would never be visited even if it was present. The equivalent one-arm match compiles just fine (expectedly). Adding an branch to the is, of course, possible, but unelegant, and really shouldn't be needed, as it can be inferred at compile time.
You can match irrefutably without in this case: though maybe we should give this special diagnostics.
I think this is too niche to deserve a special diagnostics (and I don't think we should substantially work on diagnostics for until let_chains is implemented). is defined by a desugaring: becomes: so what you really wrote is: The block is typed at which does not unify with unless it is also typed at .
I didn't know was a valid syntax. If I did, I probably wouldn't have filed the issue, because of course, in hindsight, that's how you write an infallible . (With that knowledge in mind) I agree that it's only a diagnostics issue and no language change is needed here. And I fully agree that it's a niche low-priority quirk that should maybe be fixed "someday". (I don't know what but even then I'd guess that this one is lower priority than that).
I think the appropriate thing to do here would be to lint on , which would have clarified things.
We already do.
But we do only after typechecking, and we don't if there are any errors before then. Quite a few lints have similar issues related to not happening early enough.
How do you know that the pattern is irrefutable before match checking in HAIR?
You can't, but you can write the lint in such a way that it triggers regardless. We're getting to typechecking, we should be able to detect irrefutability by then. It just can't use the standard linting machinery (like a few other lints already do to avoid being silenced by accident).
Change:
#[stable(feature = "rust1", since = "1.0.0")] impl AsRef<OsStr> for str { <ins> #[inline] </ins> fn as_ref(&self) -> &OsStr { OsStr::from_inner(Slice::from_str(self)) }

Discussion:
Godbolt link: I expect these two snippets have the same optimized asm but they don't:
I think the bigger problem here is that the quite trivial AsRef and PartialEq implementations did not get inlined. I would not expect anything to optimize well without those getting inlined.
I'm not sure we can expect these two to give you the same assembly. They are actually a bit different -- the first one will construct conditionally ( will call the closure only for ), whereas the second one will create the unconditionally before even checking if the parameter is or . As for the differences in the assembly wrt. comparisons themselves, this seems to be due to the difference between the code to check for equality of vs . I wonder, do you have a particular benchmark/workload where the first function is slower than expected?
Still, if I change the first snippet like below, [the asm][1] is different too: [1]:
is effectively a pointer cast, so it is warranted to expect assembly of at least similar quality. Inlining does not happen because we do happen to have generated machine code for these trivial functions in Tacking some s should suffice?
After inlining some methods in , I got the same asm between those two snippets:
Change:
default_hidden_visibility: false, embed_bitcode: false, emit_debug_gdb_scripts: true, <ins> requires_uwtable: false, </ins> } } }

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
use thin_vec::thin_vec; use crate::errors; <del> use crate::util::{expr_to_string, get_exprs_from_tts, get_single_str_from_tts}; </del> <ins> use crate::util::{expr_to_string, get_exprs_from_tts, get_single_expr_from_tts}; </ins> fn lookup_env<'cx>(cx: &'cx ExtCtxt<'_>, var: Symbol) -> Result<Symbol, VarError> { let var = var.as_str();

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .
Change:
<ins> // run-rustfix #[allow(dead_code)] enum Demo { A = 1, B = 2 //~ ERROR unexpected `==` //~^ expected item, found `==` } fn main() {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. 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 replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- 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
Change:
<ins> warning: unused extern crate --> $DIR/remove-extern-crate.rs:18:1 | LL | extern crate core; | ^^^^^^^^^^^^^^^^^^ help: remove it | note: lint level defined here --> $DIR/remove-extern-crate.rs:16:9 | LL | #![warn(rust_2018_idioms)] |         ^^^^^^^^^^^^^^^^ = note: #[warn(unused_extern_crates)] implied by #[warn(rust_2018_idioms)] warning: `extern crate` is not idiomatic in the new edition --> $DIR/remove-extern-crate.rs:19:1 | LL | extern crate core as another_name; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: convert it to a `use` warning: `extern crate` is not idiomatic in the new edition --> $DIR/remove-extern-crate.rs:32:5 | LL |     extern crate core; |     ^^^^^^^^^^^^^^^^^^ help: convert it to a `use` </ins>

Discussion:
Migrated from It's been mentioned/requested multiple times on the that should remove the statements when moving to Rust 2018. One of the big draws of Rust 2018's module system is that all of the "redundant" lines can finally be removed. It took some of the excitement away when I went through all of the steps and still saw them there. I think it will just be a better experience for users to see one of the tangible benefits of this change. As it is right now, they just see the in front of all of their local imports and they might not realize what a nice change the module system updates really are. After I manually removed the 's I did get my satisfying result , but let's give this to users on the first go around. If I understand correctly this should be implemented in the compiler under the lints, rather than itself. cc
I'm moving this forward up on the milestone list due to just having closed in favor of this issue, which was itself on the RC milestone.
Ok so I've some triaging of related lint issues, and I believe the current work items are: A rustfix-fixable suggestion for removing needs to be implemented. The implementation would . Currently the lint suggests switching to simply . While technically correct and handles lots of corner cases, this doesn't achieve the desired goal of actually removing annotations. We can't blanket remove all statements, for example is correctly warned to use a rather than deleting the statement outright. I'm testing out some ideas locally as well.
I believe this should be fixed by , I think the naive solution actually works well!
Change:
if triple.contains("-none") || triple.contains("nvptx") || triple.contains("switch") { target.no_std = true; } <ins> if triple.contains("emscripten") { target.runner = Some("node".into()); } </ins> target } }

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
<ins> // A regression test for #68653, which was fixed by #68938. // check-pass #![allow(incomplete_features)] #![feature(generic_associated_types)] trait Fun { type F<'a: 'a>; } impl <T> Fun for T { type F<'a> = Self; } fn main() {} </ins>

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?