jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: 5 warnings emitted </ins>

Discussion:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim
Change:
<ins> // Copyright 2016 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. // compile-flags:-Zdump-mir=NEVER_MATCHED // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </ins>

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
<del> Subproject commit cfb332005845883f2abb50fe183fc91221bad9d1 </del> <ins> Subproject commit c807fbc8ba41432388b6f590668ba81314c07c32 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
<ins> error[E0311]: the parameter type `C` may not live long enough --> $DIR/issue-92096.rs:20:33 | LL | fn call_connect<C>(c: &'_ C) -> impl '_ + Future + Send |                 -               ^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `C` will meet its required lifetime bounds |                 | |                 help: consider adding an explicit lifetime bound...: `C: 'a` error[E0311]: the parameter type `C` may not live long enough --> $DIR/issue-92096.rs:20:33 | LL | fn call_connect<C>(c: &'_ C) -> impl '_ + Future + Send |                 -               ^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `C` will meet its required lifetime bounds |                 | |                 help: consider adding an explicit lifetime bound...: `C: 'a` 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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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. --: I have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that
Change:
} if silent { <del> return false; </del> <ins> return true; </ins> } if provided > expected_max {

Discussion:
This is ICE since 1.50.0, error -ICE. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-03-17 regressed nightly: nightly-2020-11-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Thanks for bisecting, I believe is the cause.
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
claim
Change:
args="$args --env SCCACHE_DIR=/sccache --volume $HOME/.cache/sccache:/sccache" fi <ins> # By default, container volumes are bound as read-only; therefore doing experimental work # or debugging within the container environment (such as fetching submodules and # building them) is not possible. Setting READ_ONLY_SRC to 0 enables this capability by # binding the volumes in read-write mode. if [ "$READ_ONLY_SRC" != "0" ]; then SRC_MOUNT_OPTION=":ro" fi </ins> # Run containers as privileged as it should give them access to some more # syscalls such as ptrace and whatnot. In the upgrade to LLVM 5.0 it was # discovered that the leak sanitizer apparently needs these syscalls nowadays so

Discussion:
I have this totally normal config: Then I want to run Then inside the container, Bootstrap is compiled, but then emits this: My repository history is not too shallow. The only way to use the CI scripts seems to be to set . The reason download-ci-llvm doesn't work seems to be the ownership of the mount: So maybe this is an easy fix? Can we just run that somewhere? It seems to work, I'm just not sure where it would be run.
That script should set the uid of the processes inside the container to match what you use outside of the container and thus who owns the source repo: If you use podman, are you maybe using a version of podman which doesn't contain the literal string in ? And can you run outside and inside the container?
I am not using Podman
Outside the container: After
I assume this is related with your docker privileges (the user group assigned on docker). Can't reproduce this on my side.
That seems reasonable? What should that be instead?
should be able to handle this
That's very nice of you, but if I have a scuffed Docker setup on my dev machine I'd like to know in what way it's scuffed if you don't mind :sweat_smile:
By default, docker runs under root mode, and I believe this is the main issue here. On the other hand, podman runs in rootless mode by default: I was able to reproduce the problem by running podman under root privileges. I believe the problem here is more related to the nature of docker rather than an issue with your docker setup.
The snippet I mentioned in should ensure that the programs inside the container run as the same user as the one with which was invoked.
And when the user is root (e.g., running the script with root user), you get .
Change:
}, Rvalue::Repeat(..) | Rvalue::Ref(..) | <del> Rvalue::Cast(..) | </del> Rvalue::Aggregate(..) | Rvalue::NullaryOp(NullOp::Box, _) | Rvalue::Discriminant(..) => None, <ins> Rvalue::Cast(kind, ref operand, _) => { let (value, ty, span) = self.eval_operand(operand, source_info)?; self.use_ecx(source_info, |this| { let dest_ptr = this.ecx.alloc_ptr(place_ty)?; let place_align = this.ecx.layout_of(place_ty)?.align; let dest = ::interpret::Place::from_ptr(dest_ptr, place_align); this.ecx.cast(ValTy { value, ty }, kind, place_ty, dest)?; Ok(( Value::ByRef(dest_ptr.into(), place_align), place_ty, span, )) }) } </ins> // FIXME(oli-obk): evaluate static/constant slice lengths Rvalue::Len(_) => None, Rvalue::NullaryOp(NullOp::SizeOf, ty) => {

Discussion:
inlined inside a , I get a warning: however, when I involve a variable there is no warning at all but looking at the generated code it is quite clear that this panics:
It warns on current stable, but not on beta and nightly. Might be miri fallout? cc Curiously, when you take a reference (to trigger promotion to static) you get a hard error on beta and nightly (stable is still a warning). Isn't that a regression?
triage: P-medium Still want to get those warnings, but no longer P-high
Hm, what is the status of this? The PR was merged, but with , I don't get a compiler warning for the first example. For the second one I get two though? :confused:
The PR was just for the compilation error. The missing warnings just need an impl for this branch: The warning duplication is unfortunate, but if we deduplicate it, we loose warnings in other edge cases. We could deduplicate it similar to the way the notes about where the lint level was set are deduplicated (note how the second warning has no message). That would probably be the cleanest solution.
Change:
$$(HLIB$(2)_H_$(4))/libcore.rlib:  $$(TLIB$(1)_T_$(4)_H_$(3))/libcore.rlib  $$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
// except according to those terms. // xfail-test <del> fn foo() -> &'a int { </del> <ins> fn foo<'a>() -> &'a int {  //~ ERROR unconstrained region </ins> return &x; } static x: int = 5;

Discussion:
If you have a function like this: we should report an error. The only thing you could legally do in that case is fail or return a static item, so you miight as well write: This sounds like a good lint warning/error.
My vote is warning rather than error. If you're right that it's always the wrong thing to do, then you shouldn't be able to write non-unsafe code that does this that doesn't error somewhere else. And maybe you want to try doing it just while hacking / experimenting with the language.
Reproduced with This compiles successfully.
Not critical for 0.6; removing milestone
Reproduced with Still compiles successfully.
Nominating for milestone 5, production-ready
just a bug, removing milestone/nomination.
Visiting for triage email 2013-07-22 reproduced with
As of lifetime elision () we now indeed require a bound in that position. Closing.
Change:
use rustc_infer::infer::InferCtxt; use rustc_middle::hir::place::ProjectionKind; use rustc_middle::mir::FakeReadCause; <del> use rustc_middle::ty::{self, adjustment, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, adjustment, Ty, TyCtxt}; </ins> use rustc_target::abi::VariantIdx; use std::iter;

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
|         ----------- in this macro invocation | note: the lint level is defined here <del> --> $DIR/semicolon-in-expressions-from-macros.rs:2:9 </del> <ins> --> $DIR/semicolon-in-expressions-from-macros.rs:3:9 </ins> | LL | #![warn(semicolon_in_expressions_from_macros)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
source_span: Span) { use syntax_pos::DUMMY_SP; <ins> debug!("generator_interior: attempting to record type {:?} {:?} {:?} {:?}", ty, scope, expr, source_span); </ins> let live_across_yield = scope.map(|s| { self.region_scope_tree.yield_in_scope(s).and_then(|yield_data| { // If we are recording an expression that is the last yield

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
Does this issue still occur? I couldn't reproduce it from given code on playground.
I just checked with nightly 2019-06-03, and it's still there. It requires the line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type="proc-macro"] #![crate_name="redundant_semi_proc_macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn should_preserve_spans(_attr: TokenStream, item: TokenStream) -> TokenStream { eprintln!("{:?}", item); item } </ins>

Discussion:
Using nightly-2019-08-26. In we upgraded the compiler. Our tidbquery component tripped the redundantsemicolon lint (and seemingly in turn clippy::noeffect) but rustc/clippy did not tell us the line number. I couldn't find the code that triggered the lint and had to just allow both for the whole crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
It can be reproduced by cloning that PR, removing the commit that adds the s, and running .
Introduced in It has caused similar effects in other cases like CC
cc
Check-in from compiler team: Marking as P-high " as this is a regression, though admittedly one without particularly serious consequences (the lint can always be allowed). or perhaps one of you can take a stab at this? Please if you do start working on it (even if it's just to write mentoring instructions).
Also, it'd be great to get a minimized version of the problem. Therefore, marking as E-needs-mvce.
I'll work on this. Looking into it a bit, I think it has to do with the lint's interaction with custom proc macro attributes. Specifically, when the item passed to the attribute contains a redundant semicolon, every span in the is the dummy span. This occurs in both this issue and . It's definitely due to the changes to the parser, but I'm not sure why the changes would have that effect on the spans. claim
just in case you didn't see, the attempt to fix this with your PR failed the rollup, see

The new lint for excess semicolons () has some weird behaviour when the lint is triggered inside an async function that is transformed using a procedural macro. Rustc version: 1.39.0-nightly ( 2019-08-26) Compiling this: gives this output: note how the spans are all targeting the procedural macro instead of the correct line. If I remove the procedural macro or if I remove the excess semicolon, the spans are fine. This leads me to believe that it's an error in the lint, not in the macro, but maybe I'm wrong.
It is the macro's responsibility to preserve spans. What we can do is silence warnings coming from macro's, but we do that on a lint by lint basis at the moment.
Without the excess semicolon the spans for the other warnings are correct even with the macro, which led me to believe that the macro itself is not the problem. Does that mean that the macro somehow needs to support this new lint (or some family of lints)?
The fact that the other lints trigger only if the extra semicolon is there is quite weird indeed.
At my setup they trigger always (unless the compiler does not nothing and prints nothing out), however the combination + macro + excess semicolon messes up the spans. I looked at the macro and tried to use , that didn't help.