jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass fn main() { let array = [0x42u8; 10]; for b in &array { let lo = b & 0xf; let hi = (b >> 4) & 0xf; } } </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
Terminate, } <del> /// 32-bit Apple ARM uses SjLj exceptions, except for watchOS. </del> <ins> /// 32-bit ARM Darwin platforms uses SjLj exceptions. </ins> /// <del> /// I.e. iOS and tvOS, as those are the only Apple OSes that used 32-bit ARM /// devices. </del> <ins> /// The exception is watchOS armv7k (specifically that subarchitecture), which /// instead uses DWARF Call Frame Information (CFI) unwinding. </ins> /// /// <https://github.com/llvm/llvm-project/blob/llvmorg-18.1.4/clang/lib/Driver/ToolChains/Darwin.cpp#L3107-L3119> pub const USING_SJLJ_EXCEPTIONS: bool =

Discussion:
Building project using should just work, but instead it fails to link to the and symbols. The exact error is: : This worked with , I'll try to bisect it myself. label O-watchos
Ugh, don't you just love it when the culprit is yourself? It's
Change:
// start with a non-lowercase letter rather than non-uppercase // ones (some scripts don't have a concept of upper/lowercase) <del> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains('_') </del> <ins> !name.is_empty() && !name.chars().next().unwrap().is_lowercase() && !name.contains("__") && !name.chars().collect::<Vec<_>>().windows(2).any(|pair| { // contains a capitalisable character followed by, or preceded by, an underscore char_has_case(pair[0]) && pair[1] == '_' || char_has_case(pair[1]) && pair[0] == '_' }) </ins> } fn to_camel_case(s: &str) -> String { <del> s.split('_') .flat_map(|word| { </del> <ins> s.trim_matches('_') .split('_') .map(|word| { </ins> word.chars().enumerate().map(|(i, c)| if i == 0 { c.to_uppercase().collect::<String>() } else { c.to_lowercase().collect() }) <ins> .collect::<Vec<_>>() .concat() </ins> }) <ins> .filter(|x| !x.is_empty()) </ins> .collect::<Vec<_>>() <del> .concat() </del> <ins> .iter().fold((String::new(), None), |(acc, prev): (String, Option<&String>), next| { // separate two components with an underscore if their boundary cannot // be distinguished using a uppercase/lowercase case distinction let join = if let Some(prev) = prev { let l = prev.chars().last().unwrap(); let f = next.chars().next().unwrap(); !char_has_case(l) && !char_has_case(f) } else { false }; (acc + if join { "_" } else { "" } + next, Some(next)) }).0 </ins> } if !is_camel_case(name) {

Discussion:
Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in

I feel like the warning fires wrongly on this variant name in particular.
the warning fires whenever the name contains a ` if the characters directly before and after are digits?
Adding an exception for digits only will lead to to an issue later about some other non-letter case. What should be done instead, IMO, is check that the character before and after are letters and only warn then. /me shrugs. Very bikeshedy thing to discuss.
I understand wanting this to just work, but it's getting uncomfortably clever. Requiring a suppression here isn't so bad. Is this a case that comes up other than for "X86_64"?
Change:
} session::OutputExecutable => { link_natively(sess, false, obj_filename, &out_filename); <ins> // Windows linker will add an ".exe" extension if there was none let out_filename = match out_filename.extension() { Some(_) => out_filename.clone(), None => out_filename.with_extension(win32::EXE_EXTENSION) }; manifest::postprocess_executable(sess, &out_filename); </ins> } session::OutputDylib => { link_natively(sess, true, obj_filename, &out_filename);

Discussion:
Windows executables should contain embedded application manifests [1]. This is especially important for 32-bit executables, because in the absence of a manifest they are subject to UAC installer detection heuristics [2], which may cause unexpected UAC prompts or even complete failure to execute (in unattended contexts) depending on presence of certain keywords in executable's file name.
You beat me by a few hours :) Here is the description I had in : The UAC issue in is caused by a missing in the binaries. We should include the following in all binaries: In an ideal world, we would allow the user to provide a custom manifest should they wish to require UAC elevation, for example. As another example, a user might want to provide entries in order to fully support Windows 8.1 (where the / functions unless is present in the manifest). The VC++ linker has the option for the UAC part. In a traditional MinGW build, this would be implemented something like this: Where would contain something like this (application.manifest would contain the XML stuff above):
I wonder if it would be easier to skip windres altogether and write resource directly into linked executable using .
I use to add manifest but I always felt this is a hack.
As of MSVC 2008, passing to should add the necessary manifest bits for UAC.
In case anyone finds this issue, you can use in a script to solve this:
Hello. It is over 1 year later now since this comment was posted. Is this nasty work around still necessary? Or does the Rust Compiler finally supports embedding Windows Manifest Files and Resources etc. (in anyway whatsoever)? Thanks!
Change:
} fn link_dylib_by_name(&mut self, name: &str, verbatim: bool, _as_needed: bool) { <del> self.link_arg(format!("{}{}", name, if verbatim { "" } else { ".lib" })); </del> <ins> // On MSVC-like targets rustc supports import libraries using alternative naming // scheme (`libfoo.a`) unsupported by linker, search for such libraries manually. if let Some(path) = try_find_native_dynamic_library(self.sess, name, verbatim) { self.link_arg(path); } else { self.link_arg(format!("{}{}", name, if verbatim { "" } else { ".lib" })); } </ins> } fn link_dylib_by_path(&mut self, path: &Path, _as_needed: bool) {

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. --Hi all, I'm coming from to report an inconsistency in how Rust passes library names to Visual Studio's . In the project, which is driven through Meson, I expected all libraries to be found correctly. Instead, I get an error of library not found at linking time. This is caused by the following snippet of code. The above snippet hardcodes the convention when passing import or static libraries' names. However, this is not consistent with , which is already handled correctly in a separate portion of the Rust compiler: The result of the above is that Rust, under MSVC, will happily put together and , but will fail utterly when a is demanded under the present set of circumstances. This is the other half required to completely address the issue in -- I tried working around this by inserting plus setting the correct file name, as shown in , but it returns an error: This is already known and was never addressed: <!-- 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<summaryBacktrace of the big linker error</summary<p</p</details
Any update on this issue?
I see you have done quite a bit of work here, thank you! Is there anything I can do to help move this forward? I can try to build this custom branch and test if it works?
Apologies, I now see the relevant issue is already being worked on!
Change:
<ins> // Copyright 2018 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. // Check that mutable promoted length zero arrays don't check for conflicting // access // run-pass #![feature(nll)] pub fn main() { let mut x: Vec<&[i32; 0]> = Vec::new(); for i in 0..10 { x.push(&[]); } } </ins>

Discussion:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).
Change:
const VALUE: u8 = unsafe { *REG_ADDR }; //~^ ERROR dereferencing raw pointers in constants is unstable <ins> const unsafe fn unreachable() -> ! { use std::convert::Infallible; const INFALLIBLE: *const Infallible = [].as_ptr(); match *INFALLIBLE {} //~^ ERROR dereferencing raw pointers in constant functions is unstable const BAD: () = unsafe { match *INFALLIBLE {} }; //~^ ERROR dereferencing raw pointers in constants is unstable } </ins> fn main() { }

Discussion:
The code below compiles as of 1.46, but I'm not sure it should, since it dereferences a raw pointer in a const block, which is only allowed in nightly with the flag:
modify labels to +A-raw-pointers +A-const-fn
cc
Ah, that looks like the const version of the old "uninhabited match" problem... The MIR for is So somehow the deref already vanished, and hence the const analysis cannot catch it. But doesn't unsafety checking also happen on the MIR? Why does that work?
It seems that whenever the dereference is not bound to a variable, it compiles, but whenever bound to a variable, it fails to compile:
I don't believe this is an unsoundness. Unsafe code is required to cause anything here. That's the final MIR, since without this will fail to compile, it must be there for unsafety checking, thus it must also be there for const checking. Not sure why we fail to catch this.
Agreed. This is a case of "oops a nightly-only feature is available on stable", which is bad, but it is not an unsoundness.
Assigning and removing as in the prioritization working group.
The initial MIR looks like this: So probably the issue is that const-checking ignores ?
oh... yea.. we ignored it on purpose... "because it doesn't actually do anything" :upsidedownface: I guess we should visit all places within statements that we otherwise ignore during const-checking?
Well, at least we need to visit . ;)
Do we really? The check is done in , which should be called even for the projection in the place in the fake read.
Oh wait, we don't call unconditionally! That seems like... a problem.^^
Proposed a fix:
Change:
// CHECK: define{{.*}}foo145{{.*}}!type ![[TYPE145:[0-9]+]] pub fn foo146(_: Type13, _: Type13, _: Type13) { } // CHECK: define{{.*}}foo146{{.*}}!type ![[TYPE146:[0-9]+]] <ins> pub fn foo147(_: Type14<Bar>) { } // CHECK: define{{.*}}foo147{{.*}}!type ![[TYPE147:[0-9]+]] pub fn foo148(_: Type14<Bar>, _: Type14<Bar>) { } // CHECK: define{{.*}}foo148{{.*}}!type ![[TYPE148:[0-9]+]] pub fn foo149(_: Type14<Bar>, _: Type14<Bar>, _: Type14<Bar>) { } // CHECK: define{{.*}}foo149{{.*}}!type ![[TYPE149:[0-9]+]] </ins> // CHECK: ![[TYPE0]] = !{i64 0, !"_ZTSFvvE"} // CHECK: ![[TYPE1]] = !{i64 0, !"_ZTSFvvvE"}

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
<ins> // https://github.com/rust-lang/rust/issues/126376 mod a { pub mod b { pub trait C {} } } use a::*; use e as b; use b::C as e; //~^ ERROR: unresolved import `b::C` //~| ERROR: cannot determine resolution for the import //~| ERROR: cannot determine resolution for the import fn e() {} fn main() { } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: inconsistent resolution for an import', 'error: internal compiler error: inconsistent resolution for an import' 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: [resolverforlowering_raw] getting the resolver for lowering --
Isn't this example identical to EDIT: oh I see, the PR that closes doesn't actually have this test, so it's possible this is a different ICE.
This one has an additional which indeed causes the ICE to trigger again :laughing:
Regression in nightly-2020-11-09 commit[0] 2020-11-07: Auto merge of - Mark-Simulacrum:debug-asserts, r=pietroalbini commit[1] 2020-11-07: Auto merge of - Mark-Simulacrum:revert-, r=petrochenkov commit[2] 2020-11-08: Auto merge of - petrochenkov:mergetarg, r=Mark-Simulacrum commit[3] 2020-11-08: Auto merge of - lcnr:revert75443, r=nikomatsakis commit[4] 2020-11-08: Auto merge of - m-ou-se:rollup-3jp1ijj, r=m-ou-se commit[5] 2020-11-08: Auto merge of - petrochenkov:visitok, r=Aaron1011

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().isnone()'', 'thread 'rustc' panicked at 'assertion failed: ().isnone()'' 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: [resolverforloweringraw] getting the resolver for lowering --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc as this looks 99% like and you fixed that one recently ^^
claim. I will investigate it in my spare time.
Change:
LL | #[doc(alias("bar"))] |       ^^^^^^^^^^^^ <del> error: aborting due to 3 previous errors </del> <ins> error: '"' character isn't allowed in `#[doc(alias = "...")]` --> $DIR/check-doc-alias-attr.rs:10:7 | LL | #[doc(alias = """)] |       ^^^^^^^^^^^^ error: 'n' character isn't allowed in `#[doc(alias = "...")]` --> $DIR/check-doc-alias-attr.rs:11:7 | LL | #[doc(alias = "n")] |       ^^^^^^^^^^^^ error: 'n' character isn't allowed in `#[doc(alias = "...")]` --> $DIR/check-doc-alias-attr.rs:12:7 | LL |   #[doc(alias = " |  _______^ LL | | ")] | |_^ error: ' ' character isn't allowed in `#[doc(alias = "...")]` --> $DIR/check-doc-alias-attr.rs:14:7 | LL | #[doc(alias = " ")] |       ^^^^^^^^^^^ error: 't' character isn't allowed in `#[doc(alias = "...")]` --> $DIR/check-doc-alias-attr.rs:15:7 | LL | #[doc(alias = "t")] |       ^^^^^^^^^^^^ error: aborting due to 8 previous errors </ins>

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
} }; <del> self.tcx.emit_spanned_lint( lint, tcx.hir().local_def_id_to_hir_id(first_id), MultiSpan::from_spans(spans), diag, ); </del> <ins> self.tcx.emit_spanned_lint(lint, first_hir_id, MultiSpan::from_spans(spans), diag); </ins> } <del> fn warn_dead_fields_and_variants( </del> <ins> fn warn_multiple( </ins> &self, def_id: LocalDefId, participle: &str, <del> dead_codes: Vec<DeadVariant>, </del> <ins> dead_codes: Vec<DeadItem>, </ins> is_positional: bool, ) { let mut dead_codes = dead_codes .iter() .filter(|v| !v.name.as_str().starts_with('_')) <del> .collect::<Vec<&DeadVariant>>(); </del> <ins> .collect::<Vec<&DeadItem>>(); </ins> if dead_codes.is_empty() { return; } dead_codes.sort_by_key(|v| v.level); for (_, group) in &dead_codes.into_iter().group_by(|v| v.level) { <del> self.warn_multiple_dead_codes( </del> <ins> self.lint_at_single_level( </ins> &group.map(|v| v.def_id).collect::<Vec<_>>(), participle, Some(def_id),

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
use crate::sys_common::{AsInner, IntoInner}; /// Raw file descriptors. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub type RawFd = raw::c_int;

Discussion:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.
Change:
<ins> error[E0637]: `&` without an explicit lifetime name cannot be used here --> $DIR/issue-109071.rs:8:17 | LL |     type Item = &[T]; |                 ^ explicit lifetime name needed here error[E0107]: missing generics for struct `Windows` --> $DIR/issue-109071.rs:7:9 | LL | impl<T> Windows { |         ^^^^^^^ expected 1 generic argument | note: struct defined here, with 1 generic parameter: `T` --> $DIR/issue-109071.rs:5:8 | LL | struct Windows<T> {} |        ^^^^^^^ - help: add missing generic argument | LL | impl<T> Windows<T> { |                +++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0107, E0637. For more information about an 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. --<!-- 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
Minimized with : label +S-bug-has-mcve
searched toolchains through Regression in
Alternative: Would the error change if the compiler is built with ?
Triage: This is no longer ICE since today's nightly, I assume fixed it. Marking as E-needs-test just in case regression tests there didn't cover this case. labels: +E-needs-test