jiebi/CodeConvo huggingface dataset:
Change:
step_msg "looking for build programs" probe_need CFG_PERL        perl <del> probe_need CFG_PYTHON      python python2.6 python2 python3 </del> probe_need CFG_CURL        curl <ins> probe_need CFG_PYTHON      python2.7 python2.6 python2 python python_version=$($CFG_PYTHON -V 2>&1) if [ $(echo $python_version | grep -c '^Python 2.[4567]') -ne 1 ]; then err "Found $python_version, but LLVM requires Python 2.4-2.7" fi </ins> # If we have no git directory then we are probably a tarball distribution # and shouldn't attempt to load submodules

Discussion:
LLVM cannot build with python 3 but tries anyway. This has caused confusion a number of times.
This was fixed by the pull req. Closing.
Turns out this didn't actually fix the problem. At the time I had (wrongly) assumed that the Python version detected during Rust's configure phase was being somehow communicated to LLVM. Looking a bit more closely, I'm not sure that Rust does anything at all with the detected version of Python; perhaps an artifact of an era when Rust had a Python dependency? bbrittain (who rediscovered this bug) and I discussed some hacky workarounds and finally decided that the best thing to do is to send a patch upstream to LLVM (which, despite having a hard dependency on Python 2, never bothers to check for Python 3 and just fails with cryptic errors). Once the fix is accepted we can integrate it into Rust's fork of LLVM.
(I'm bbrittain) LLVM assumes, and has hardcoded, that means a python2.x. Bleeding-edge linux distros, such as arch, now have 'python' mean python3. It's easy to symlink around, but it really would be better to just fix it.
Reopening. you have a pull request on brson/llvm that I completely forgot about. Is it still appropriate to merge? Do you know if llvm has the fix upstream yet? Sorry I lost your patch. Feel free to contact me privately if that happens again.
This does continue to come up. Would be nice to fix definitively.
LLVM has not fixed it upstream. frankly, I couldn't find a way to submit the bug fix due to them using SVN...
erickt has rebased us onto LLVM HEAD and I rebased your patch on top of that. Hopefully this will get in today.
sweet, thanks!
The fix is on incoming.
Change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // 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. // error-pattern:capacity overflow use std::collections::hashmap::HashMap; use std::uint; use std::mem::size_of; fn main() { let threshold = uint::MAX / size_of::<(u64, u64, u64)>(); let mut h = HashMap::<u64, u64>::with_capacity(threshold + 100); h.insert(0, 0); } </ins>

Discussion:
The recent attempts to improve hashmap seem to have exposed a bug in regionck where it fails to link the lifetimes of ref bindings in some situations. A mostly minimized test case is here: This test fails to compile but (I believe) should succeed. The problem is that the lifetime of the binding inside the callback from is not "linked" (in regionck terminology) to the lifetime , and hence region inference infers a lifetime for that is too small. It was not immediately obvious what the best way is to fix this -- the code around handling ref bindings seems a bit ... off in regionck, so I need to think about it some. Perturbing the code in various ways can workaround the issue, which is bad for making minimized test cases but good for landing the hasmap patch in the meantime!
I've run into (I think) another manifestation of this issue that forces the destructuring of a reference to a tuple from the arguments to the closure body: This works, but this does not
I think this is the original problem, updated to current syntax: error: Actually, maybe this should be using something other than Box... ugh old closures.
If you use a boxed closure, remember to box it: This runs on modern rustc.
Ah duh. Thanks!
Change:
<ins> // check-pass // aux-build:test-macros.rs #![feature(stmt_expr_attributes, proc_macro_hygiene)] extern crate test_macros; use test_macros::identity_attr; #[identity_attr] fn main() { let _x; let y = (); #[identity_attr] _x = y; } </ins>

Discussion:
I tried this code: I expected the code to compile sucessfully, but got an ICE instead: (This is procedural-macro-related. I can't reproduce without a procedural macro.) This used to work and regressed in . <details<summaryBacktrace</summary<p</p</detailscc
If this code only works on nightly, then I don't think it's a . However, we don't have a label, so ...
This will be fixed by , which handles attributes on expressions in a more systematic way. As a side note, is currently parsed as
Do you want to add to that PR then?
We'll still need to add a regression test.
Assigning P-high as .20on.20nightly.20with.20.60stmt_ex.E2.80.A6) and removing I-prioritize.

I tried this code: and I expected to see this happen: the compiler complained was missing, or on nightly, after adding , compiled successfully, just like . Instead, this happened: the assertion failed. The compiler gave an empty as to the procedural macro: Edit: I found this in the compiler's log: I tried this with: nightly-2020-12-08 () nightly-2020-12-07 () beta () stable () cc
The pretty-print/reparse check has been removed, so this should hopefully be fixed on the latest nightly.
Confirmed that this is fixed in latest nightly, thanks! :heart: Do I need to leave this issue open (possibly for a regression test)?
That sounds like a good idea.
Change:
<ins> error[E0220]: associated type `Value` not found for `R` --> $DIR/normalize-conflicting-impls.rs:10:8 | LL |     R::Value: DimName, |        ^^^^^ associated type `Value` not found error[E0119]: conflicting implementations of trait `Allocator<_, ()>` for type `DefaultAllocator` --> $DIR/normalize-conflicting-impls.rs:14:1 | LL | / impl<N, R> Allocator<N, R> for DefaultAllocator LL | | where LL | |     R::Value: DimName, | |______________________- first implementation here ... LL |   impl<N> Allocator<N, ()> for DefaultAllocator {} |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `DefaultAllocator` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0220. For more information about an error, try `rustc --explain E0119`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc
Change:
if let hir::ExprWhile(ref cond, ..) = e.node { if let hir::ExprLit(ref lit) = cond.node { if let ast::LitKind::Bool(true) = lit.node { <del> cx.span_lint(WHILE_TRUE, e.span, "denote infinite loops with loop { ... }"); </del> <ins> if lit.span.ctxt() == SyntaxContext::empty() { cx.span_lint(WHILE_TRUE, e.span, "denote infinite loops with loop { ... }"); } </ins> } } }

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
LL | const MUTABLE_BEHIND_RAW: *mut i32 = &UnsafeCell::new(42) as *const _ as *mut _; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:346:17 </del> <ins> thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:356:17 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
|              |       not allowed in type signatures |              help: replace with the correct return type: `Pointer<i32>` <del> error: aborting due to 1 previous error </del> <ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for functions --> $DIR/issue-77179.rs:17:25 | LL |     fn bar() -> Pointer<_>; |                         ^ |                         | |                         not allowed in type signatures |                         help: use type parameters instead: `T` error: aborting due to 2 previous errors </ins> For more information about this error, try `rustc --explain E0121`.

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. -- (not minimized yet) searched nightlies: from nightly-2024-01-11 to nightly-2024-01-13 regressed nightly: nightly-2024-01-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
label -E-needs-mcve +S-has-mcve +F-impltraitinassoctype +requires-nightly
Change:
}; let externally_visible = if !impls.is_empty() && let Some(def_id) = trait_def_id.as_local() <del> && tcx.effective_visibilities(()).is_exported(def_id) </del> <ins> // We may be executing this during typeck, which would result in cycle // if we used effective_visibilities query, which looks into opaque types // (and therefore calls typeck). && tcx.resolutions(()).effective_visibilities.is_exported(def_id) </ins> { true } else {

Discussion:
No response No response This code is originally extracted from a reduction of a problem found hit on a . I reduced the code down to something that, confusingly, provides an incorrect diagnostics message. Originally, the dynamic dispatch were , I just substituted them. The nightly toolchain as of today behaves the same. As a note, the correct output is provided if the statement is commented out, which is why I think this is related to , but maybe not the same.
This is a duplicate of , so I'll close this in favor of that. I do agree that it's a diagnostic issue, so I will fix it.

No response cc No response No response
Is there any workaround for this issue before a patch lands?
Change:
[`split_off`]: https://doc.rust-lang.org/nightly/collections/linked_list/struct.LinkedList.html#method.split_off [drop]: https://github.com/rust-lang/rust/pull/24935 <del> Version 1.0.0 (May 2015) </del> <ins> Version 1.0.0 (2015-05-15) </ins> ======================== * ~1500 changes, numerous bugfixes

Discussion:
Pages like Wikipedia/Wikidata need to prove that a given information is correct. The announcement blog posts seem to be the only obvious place to look up the the exact release dates. Blog post URLs are not necessarily stable over time. It would be simpler to just refer to
They already contain the month and the year, is the day that important? (that said, I don't see the harm, I was just like "I thought we did this already")
That probably depends on the context. Most software on Wikidata has the complete date defined along the versions. Does it hurt? If the days where given, what could be reasons to remove them? I would add the days in a PR myself, just wanted to make sure there is no opposition. I suggest we use ISO-format. The dates are currently defined in Wikdata as
Change:
pub const WAIT_OBJECT_0: DWORD = 0x00000000; pub const WAIT_TIMEOUT: DWORD = 258; <ins> pub const WAIT_FAILED: DWORD = 0xFFFFFFFF; </ins> #[cfg(target_env = "msvc")] pub const MAX_SYM_NAME: usize = 2000;

Discussion:
Considering following snippets: Currently on linux, the spawned thread will just panic at option unwrap which happen inside std library: It makes no sense to call join inside the associated thread, but a meaningless panic is sure not the good way to handle this situation. Maybe we should return an error which contains the join handle, so the caller can recover the failure. If panic is preferred, then a more friendly message should be good for users.
This seems like a reasonable-ish panic, though it would perhaps be better to have the error be returned within the result, though the current behavior is as documented, so I think it's reasonable.

Gives (on playground): There are two problems here: error message is absolutely terrible. the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.
Possibly in or otherwise, but this seems to have since been fixed -- this now deadlocks.
Change:
builder.update_submodule(&Path::new("library").join("stdarch")); <ins> // Profiler information requires LLVM's compiler-rt if builder.config.profiler { builder.update_submodule(&Path::new("src/llvm-project")); } </ins> let mut target_deps = builder.ensure(StartupObjects { compiler, target }); let compiler_to_use = builder.compiler_for(compiler.stage, compiler.host, target);

Discussion:
When using in the to enable profiling, having a local copy of is required. If no such copy is present, errors about missing libraries are emitted and the build fails. Expected behavior: Bootstrap initializes the submodule when is enabled. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This should be pretty easy to fix - call in if profiling is enabled.
claim
Change:
// Sort types by insertion order types.sort_by_key(|t| t.1); <del> // Store the generator types and spans into the tables for this generator. let interior_types = types.iter().cloned().map(|t| t.0).collect::<Vec<_>>(); visitor.fcx.inh.tables.borrow_mut().generator_interior_types = interior_types; // Extract type components let type_list = fcx.tcx.mk_type_list(types.into_iter().map(|t| (t.0).ty)); </del> // The types in the generator interior contain lifetimes local to the generator itself, // which should not be exposed outside of the generator. Therefore, we replace these // lifetimes with existentially-bound lifetimes, which reflect the exact value of the

Discussion:
Hyper fails to compile on Rust master () <details</details
fyi
I also get this with on futures-rs <details</details
getting this while trying to compile rust itself(): <details</details
Confirming bisection range is
guessing it's PR attempting rust compilation with reverted like so: <details</detailsthis might take a while...
It's not it, surprisingly enough(for me). (manually)Reverting that PR fails the same. (that is, applied this on top of rust commit ) <details</details<details</details
? This PR adds to typeck-table which is stable-hashed, and the hyper ICE is happening on by querying that table, which looks relevant.
I've reversed-applied the patch from (aka reverted PR ) on top of rust like this , and the results are(74mins later, at least): it passed!(failed later, on clippy_lints, but that's unrelated) So that's the problematic PR, thanks Since rust got updated compared to my previous try, I'll re-apply this PR on top of what already worked just now to see if it indeed fails with it! <sWill post new comment with the update.</sConfirmed the ICE is back with that PR, using 's test-case: <details</details
Minimized test-case:
Thanks self-assigning to look into this (since I caused it with ) - if anyone else wants to look into fixing also, please feel free.
I have a WIP fix:
Change:
parent_prefix, use_tree, nested ); <del> if nested { </del> <ins> // Top level use tree reuses the item's id and list stems reuse their parent // use tree's ids, so in both cases their visibilities are already filled. if nested && !list_stem { </ins> self.r.feed_visibility(self.r.local_def_id(id), vis); }

Discussion:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!
Change:
<ins> warning: unexpected `cfg` condition value --> $DIR/values-target-json.rs:13:7 | LL | #[cfg(target_os = "linuz")] |       ^^^^^^^^^^^^------- |                   | |                   help: did you mean: `"linux"` | = note: expected values for `target_os` are: aix, android, cuda, dragonfly, emscripten, ericos, espidf, freebsd, fuchsia, haiku, hermit, horizon, illumos, ios, l4re, linux, macos, netbsd, none, nto, openbsd, psp, redox, solaris, solid_asp3, tvos, uefi, unknown, vita, vxworks, wasi, watchos, windows, xous = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </ins>

Discussion:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> error[E0080]: evaluation of constant value failed --> $DIR/fail-const-eval-issue-121099.rs:9:31 | LL | global_asm!("/* {} */", const 1 << 500); |                               ^^^^^^^^ attempt to shift left by `500_i32`, which would overflow error[E0080]: evaluation of constant value failed --> $DIR/fail-const-eval-issue-121099.rs:11:31 | LL | global_asm!("/* {} */", const 1 / 0); |                               ^^^^^ attempt to divide `1_i32` by zero error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0080`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim
Change:
<ins> // Copyright 2014-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. struct Test; struct Test2 { b: Option<Test>, } struct Test3(Option<Test>); impl Drop for Test { fn drop(&mut self) { println!("dropping!"); } } impl Drop for Test2 { fn drop(&mut self) {} } impl Drop for Test3 { fn drop(&mut self) {} } fn stuff() { let mut t = Test2 { b: None }; let u = Test; drop(t); t.b = Some(u); //~^ ERROR partial reinitialization of uninitialized structure `t` let mut t = Test3(None); let u = Test; drop(t); t.0 = Some(u); //~^ ERROR partial reinitialization of uninitialized structure `t` } fn main() { stuff() } </ins>

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.