jiebi/CodeConvo huggingface dataset:
Change:
self.session, ident.span, E0754, <del> "trying to load file for module `{}` with non ascii identifer name", </del> <ins> "trying to load file for module `{}` with non-ascii identifier name", </ins> ident.name ) .help("consider using `#[path]` attribute to specify filesystem path")

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
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. // Tests the coercion casts are handled properly #![feature(rustc_attrs)] #[rustc_mir] fn main() { // This should produce only a reification of f, // not a fn -> fn cast as well let _ = f as fn(&()); } fn f<'a>(_: &'a ()) { } </ins>

Discussion:
Compiling the crate with on ARM Linux: or : This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a , erm instead...
More ICEy stuff: coming from crate.
Minimal reproduction: It's the that is the problem. What happens is that we first reify to a function pointer, then try to cast the function pointer itself. It seems that we don't expect an cast in the MIR. I'm pretty sure that is only valid when it's a no-op, so we can probably just handle it MIR translation. that seem correct?
I some code to not build noop casts, the lifetimes may be different here though?
possibly, doing first and using in the cast works, so I'd say that lifetimes are the most likely source of difference between the two types in the cast. Do we have a lifetime-ignoring comparison we could use in this case?
Problem is, you can't ignore lifetimes, what if this is a to cast? There might be another way to tell that a cast only triggered a coercion, at the HAIR level. EDIT: Well, actually, the good old is a reification coercion + ptr-to-int cast.
do you mind giving a backtrace for that second error and opening a new issue for it (since it's unrelated to the two in the main post). If you could reduce it to a smaller reproduction, that would be even better.
There were no backtraces, unfortunately. Let's clarify one thing though - is turning off for a single crate and then resuming the mir'ed build, ok? That's how I arrived at the latter issue. (edit: wasn't the problem)
Actually MIR compilation has been bootstrappable for the compiler for a while now, so trying to use it for more complex codebases is really valuable, since it finds bugs like this.
The compiler doesn't generate a backtrace even if you set ?
That was the case indeed. (both ended in a segfault) -original message- Subject: Re: From: Eduard-Mihai Burtescu Date: 01.05.2016 12:22 The compiler doesn't generate a backtrace even if you set ? You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:
Yeah, that's why I tried it - that whole sentence was a big pun on the word mir. (meaning both peace and world)
Change:
ast_map::NodeTraitItem(ref trait_method) => { match **trait_method { ast::ProvidedMethod(ref method) => { <ins> if contains_nodebug_attribute(method.attrs.as_slice()) { return FunctionDebugContext { repr: FunctionWithoutDebugInfo }; } </ins> (method.pe_ident(), method.pe_fn_decl(), method.pe_generics(),

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
relative_from: Some("") ); <ins> tc!("foo//", "foo", eq: true, starts_with: true, ends_with: true, relative_from: Some("") ); tc!("foo///", "foo", eq: true, starts_with: true, ends_with: true, relative_from: Some("") ); </ins> tc!("foo/.", "foo", eq: true, starts_with: true,

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. --I tried : I expected to see this happen: Different hashes since these represent different paths. Instead, this happened: The hashes are equal. This makes sense for redundant path separators (e.g. ), but not for all path separators. I a test case to the standard library — which fails. The relevant code is probably around which last changed in If I revert that commit, the error persists. It looks like the relevant change is , if I revert that commit the test passes. This was the solution I opted for downstream (in ) before performing this investigation. I tested this on stable (1.79.0), nightly (1.81.0), and on (). Discovered via
is not a cryptographic hash, so it does not promise a collision probability so low that practically all inputs map to distinct outputs. So if the correctness of your program relies on the absence of collisions then it's your program that's wrong, not . There may be some quality-of-implementation argument about avoiding collisions for data patterns that are likely to coexist. I'm not sure if it is the case here, I'll have to think about it. And even if it is then there also is the matter of making such a avoidance fast. The current code is optimized for speed.
I think that's a fair point, but the current implementation already goes out if its way to create equal hashes for paths like and — why is and different? It seems like a very surprising collision for a user to encounter. Thanks for taking a look!
The difference is that is a companion for . If things compare equal then they must hash the same because that's what hashmaps rely on. and do compare equally because normalizes the dot away. Therefore they must hash equally, which is why Hash must spend effort on that. Things comparing inequal does not require the Hash to be different. Instead it's only a matter of quality-of-implementation whether they produce distinct hashes, not a matter of correctness.
That's a great point, thanks for clarifying. I agree this is not a "correctness" problem, but more of a practical consideration for the hashing algorithm.
Change:
pub fn target() -> Target { let mut base = super::windows_msvc_base::opts(); <del> base.cpu = "i686".to_string(); </del> <ins> base.cpu = "pentium4".to_string(); </ins> Target { llvm_target: "i686-pc-windows-msvc".to_string(),

Discussion:
noticed this on IRC. and in fact on all other triples (except iOS, which is technically called ), a SSE2-capable microarchitecture is assumed. said that this was copied from Clang. Not doing so on MSVC might be an accident, and a rather costly one.
Specifically, in the target spec, we have: , unlike every other target which assumes (except for Mac, which assumes , which is newer, so that's fine).
cc who wrote that code. Is this an intentional quirk of the MSVC toolchain?
Oh dear no this was not intentional at all, I just assumed everything was ! Feel free to send a PR to update!
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. #![feature(macro_rules)] macro_rules! foo2 { () => { "foo" } } macro_rules! foo { () => { foo2!() } } fn main() { assert_eq!(concat!(foo!(), "bar"), "foobar") } </ins>

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
err, pick.item.def_id, rcvr.hir_id, <del> *rcvr_ty, </del> <ins> Some(*rcvr_ty), </ins> ); if pick.autoderefs == 0 && !trait_in_other_version_found { err.span_label(

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
<del> Subproject commit 147ea8f400de3ca529abcb5eb7b65f84a4896ae9 </del> <ins> Subproject commit 325682ad56d23369059ea93d5a8d44e5782e41cf </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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! And nominating for compiler team prioritization.
Change:
#[cfg(not(target_os = "macos"), not(target_os = "android"))] pub unsafe fn yield_now() { assert_eq!(pthread_yield(), 0); } <ins> // Issue #6233. On some platforms, putting a lot of data in // thread-local storage means we need to set the stack-size to be // larger. #[cfg(target_os = "linux")] unsafe fn get_min_stack(attr: &libc::pthread_attr_t) -> libc::size_t { __pthread_get_minstack(attr) } #[cfg(not(target_os = "linux"))] unsafe fn get_min_stack(_: &libc::pthread_attr_t) -> libc::size_t { 0 } </ins> extern { fn pthread_create(native: *mut libc::pthread_t, attr: *libc::pthread_attr_t,

Discussion:
Linking with certain external libraries can inflate the required amount of thread local storage to astronomical proportions. When the Rust runtime tries to create its threads, it requests a stack size independent of the TLS size, which can lead to pthreadcreate() failing with EINVAL when the stack size is smaller than the TLS size. This was apparently an issue for the Go runtime as well (). A potential workaround is to add statictls_size (+ possibly a guard page) to the requested stack size, but it's arguably a bug in glibc that TLS comes out of the requested stack, instead of being to it. This solution is also admittedly not very pleasing...
I made a mistake. The workaround should actually be to add _pthreadgetminstack(&attr) to the requested size in It's still not very pleasing.
This is the bug in glibc
Still relevant, but it's an upstream bug. Removing E-easy
Triage: we still call without adjusting for so I assume that the work-around hasn't been implemented, and the upstream bug is still open (and without activity for more than 3 months).
Triage: still a bug even with the pure Rust runtime. With it crashes with: and without that it runs fine. I'll attempt to fix it now.
(The above crash appears to not happen on Mac OSX; I'm on Linux.) I opened ; but I don't think that work-around is complete enough to close this.
My patch caused people linking errors ( is apparently not in all versions of glibc (works in 2.17, fails with 2.13), being a private function), so I'm reverting it in .
Change:
use std::env; <del> use crate::spec::{FramePointer, SplitDebuginfo, TargetOptions}; </del> <ins> use crate::spec::{FramePointer, LldFlavor, SplitDebuginfo, TargetOptions}; </ins> pub fn opts(os: &str) -> TargetOptions { // ELF TLS is only available in macOS 10.7+. If you try to compile for 10.6

Discussion:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.
Change:
<ins> fn main() { println!(include!("<leading-lt")); println!(include!("trailing-gt>")); } </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. --Requirement: Create an empty file called '', i.e. using <!-- 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
Hmm, we should only disallow (since that's what we use for non-real "files") although I guess or even just might be a valid path itself? Internally we can tell apart between the two, I'm guessing this is to avoid tools seeing something with or in it and misinterpreting it as not a real file? But in that case we'd want a real error not an assert. cc
Marked as p-medium based on the discussion on the
PR with fix:
Change:
<del> Subproject commit 5e49856003f33aa5781a0edca148be21025e18e7 </del> <ins> Subproject commit 6b9281d2b2f0ebb94838814b1e8ace2de4b7035b </ins>

Discussion:
When attempting to build rustc without optimzations, linking of fails because: I guess this can be fixed by either compiling as PIC or by making it not depend on . Which would be the correct fix? Intuitively I would say that should not have any dependencies.
The submodule still needs to be updated
Change:
use rustc_ast_pretty::pprust; use rustc_attr::{self as attr, is_builtin_attr, HasAttrs}; use rustc_data_structures::map_in_place::MapInPlace; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_errors::{Applicability, PResult}; use rustc_feature::Features; use rustc_parse::parser::Parser;

Discussion:
First reported to me at I believe the stack overflow is in rustc itself. when compiled yields: where nightly today is:
Assigning as and removing .
It would be nice to bisect this one if possible ... ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-05 to nightly-2020-07-22 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
cc for anyone wanting to fix this, these kind of bugs are very easy to fix. You run rustc in until you get a stack overflow, then you look at the backtrace and look for recursion in there. Then you break the recursion overflow by inserting a use of at the recursive call site.
That sounds a good first bug to me. I'll give it a shot.
Change:
<ins> // aux-build:realcore.rs #![crate_name = "real_gimli"] #![feature(staged_api, extremely_unstable)] #![unstable(feature = "rustc_private", issue = "none")] extern crate realcore; #[unstable(feature = "rustc_private", issue = "none")] pub struct EndianSlice; #[unstable(feature = "rustc_private", issue = "none")] impl realcore::Deref for EndianSlice {} </ins>

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.
Change:
Unexplained, } <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, Debug)] </ins> pub(in crate::borrow_check) enum LaterUseKind { TraitCapture, ClosureCapture,

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
let sz_a = self.a.size(); if A::MAY_HAVE_SIDE_EFFECT && sz_a > self.len { for _ in 0..sz_a - self.len { <ins> self.a_len -= 1; </ins> self.a.next_back(); } <del> self.a_len = self.len; </del> <ins> debug_assert_eq!(self.a_len, self.len); </ins> } let sz_b = self.b.size(); if B::MAY_HAVE_SIDE_EFFECT && sz_b > self.len {

Discussion:
Yet another soundness bug in Zip's TRA specialization. Line 300 is not called when line 298 panics. This leaves outdated, which results in calling with an invalid index in line 242. Here is a that demonstrates creating two mutable references to the same memory location without unsafe code. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
How close is this to ?
The same functions are involved but the aspects that interact to cause unsafety are quite different. claim
I agree, this is much closer to .
Change:
#![allow(incomplete_features)] #![feature(inline_const_pat)] <ins> #![feature(generic_const_exprs)] </ins> // rust-lang/rust#82518: ICE with inline-const in match referencing const-generic parameter fn foo<const V: usize>() { <del> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } </del> <ins> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } } const fn f(x: usize) -> usize { x + 1 } fn bar<const V: usize>() where [(); f(V)]: { match 0 { const { f(V) } => {}, //~^ ERROR constant pattern depends on a generic parameter //~| ERROR constant pattern depends on a generic parameter _ => {}, } </ins> } fn main() { foo::<1>(); <ins> bar::<1>(); </ins> }

Discussion:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics