jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Regression test for #106269 //@ assembly-output: emit-asm //@ compile-flags: --crate-type=lib -O -C llvm-args=-x86-asm-syntax=intel //@ only-x86_64 //@ ignore-sgx pub struct S { a: u8, b: u8, c: u8, d: u8, } // CHECK-LABEL: manual_eq: #[no_mangle] pub fn manual_eq(s1: &S, s2: &S) -> bool { // CHECK: mov [[REG:[a-z0-9]+]], dword ptr [{{[a-z0-9]+}}] // CHECK-NEXT: cmp [[REG]], dword ptr [{{[a-z0-9]+}}] // CHECK-NEXT: sete al // CHECK: ret s1.a == s2.a && s1.b == s2.b && s1.c == s2.c && s1.d == s2.d } </ins>

Discussion:
The implementation produces worse code than the equivalent C++ code (, ) The resulting assembly should load and compare a single u64: The assembly loads and compares each u8 individually: <!-- 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. --:
With more aggressive compilation flags I am seeing (latest Nightly):
What flags did you use?
-O -Z mir-opt-level=4
Looks like the first two comparisons gets flattened into one block, and that prevents detection of the whole pattern.
(enabled at ) is the MIR opt which merges the short-circuiting failure paths into 1, and allows to reduce this to a pattern which can be turned into a memcmp.
might improve this. I noticed in it's doing dances: which might be no longer needed once it's and it can thus just compare them both directly. There's also something going on here related to the short-circuiting that I don't understand. If I change it to Then it optimizes as expected 's definitely marked either way, so LLVM ought to be able to move the loads early either way.
Short-circuiting is relevant in that moving everything into one block is generally non-profitable. There is a special pass that detects this pattern (MergeICmps) and converts it into memcmp/bcmp, which is then later expanded into a target-specific efficient comparison sequence. This is a backend IR pass, so you don't see it in output. However, it requires a pretty specific pattern, and does not handle the case where the control flow has been partially flattened and one pair of comparisons uses a select rather than a branch. Your X86 example adds insult to injury by actually vectorizing those two i8 comparisons: That looks pretty clearly non-profitable: Edit: Filed for the SLPVectorizer issue.
I suppose this opt would be specifically enabled by our optimization semantics allowing spurious reads. No change since the add, though. The pass may be affected by being accepted.
Looks like this is fixed now, we should have a test for this if we don't already
Change:
} let profile_var = |name: &str| { <del> let profile = if self.config.rust_optimize { "RELEASE" } else { "DEV" }; </del> <ins> let profile = if self.config.rust_optimize.is_release() { "RELEASE" } else { "DEV" }; </ins> format!("CARGO_PROFILE_{}_{}", profile, name) };

Discussion:
It would be nice if we could speed up stage1 library builds by building it with less opts and no debuginfo. had the idea to control this with something like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
i'm going to use as a separate more broad issue for - i'll repurpose this to just be for (which is a lot simpler to add)
mentoring instructions: add this option to the struct, then around , set
Can we confirm before we land this support that this is actually a significant win in practice? I recall historically having issues with optimize = false equivalents where the net effect is broken and slower tests - I would prefer to avoid landing support we don't want to actually support :)
this is especially useful in combination with - optimizing only rustc and not std should be a speedup even if we include the time taken for tests.
claim
Maybe we should just generalize the config value to a number/boolean, instead of adding a new attribute?
Change:
if rust_type == RustType.STD_NONZERO_NUMBER: return StdNonZeroNumberSummaryProvider(valobj, dict) <ins> if rust_type == RustType.STD_PATHBUF: return StdPathBufSummaryProvider(valobj, dict) if rust_type == RustType.STD_PATH: return StdPathSummaryProvider(valobj, dict) </ins> return ""

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
def check_vendored_status(self): """Check that vendoring is configured properly""" <ins> # keep this consistent with the equivalent check in rustbuild: # https://github.com/rust-lang/rust/blob/a8a33cf27166d3eabaffc58ed3799e054af3b0c6/src/bootstrap/lib.rs#L399-L405 </ins> if 'SUDO_USER' in os.environ and not self.use_vendored_sources: if os.getuid() == 0: self.use_vendored_sources = True

Discussion:
Trying to build Rust 1.63.0 it fails with the error below:
Hm, so I can't immediately reproduce -- can you say more about what sources you're using to build? is the tarball I used to make an attempt at reproducing. You might also want to check if you've enabled the use of vendored sources ( should contain vendor = true under [build]).
We are using $ md5sum /package/pkg/rustc-1.63.0-0/build/rustc-1.63.0- /package/pkg/rustc-1.63.0-0/build/rustc-1.63.0- We did not have that in our build script. It worked without in the past. Could you refer me to further details, why it’s needed?
That tarball should be content equivalent to .xz, just with gzip compression. I don't see why we would've broken a workflow that worked in the past. Can you link me to the build script you're using? --frozen is passed if we detect that you're running either with . Rustbuild checks for sudo , while our Python script has a slightly different check . Maybe your environment changed in such a way that the Python check isn't true while the rustbuild check is? That would explain the error here. (Setting vendor = true in will override the detection logic here and just enable using the vendored sources from the tarball).
The files are in , and it’s merge/pull request $ git clone $ cd pkg-scripts $ git checkout add-rustc-1.63.0-0-with-cbindgen-0.24.3 $ sudo rustc-1.63.0- # … is what we use. should work in non-MarIuX environment (our distribution). Adapt in the script to your liking.
(Edited last comment.)
It looks like you were previously on 1.61, right? landed in 1.62, which introduced the difference[^1] between handling in and the Rust component for whether we're running inside sudo (as you do). I suspect that difference made us start using vendoring (though not sure), or stop, but either way, it's likely the cause of your problem.

I'm going to go ahead and mark this as E-easy -- we should likely move the Rust code to use the same getuid() == 0 check. I believe we can do that with and appropriately cfg that if needed (based on what CI complains about). [^1]: that I pointed out in
Yes, we did. Thank you for the analysis. If you want us to test anything, please tell us.
Once merges (and we release a new nightly ~24 hours after that) it'd be great to retest with a nightly src tarball in your environment to confirm this is fixed, but also fine to just wait until the next stable release including it and file a new bug if not. That'll be 1.64, releasing September 22nd. (I marked the PR as beta-backport).
Change:
<del> //@ known-bug: #123955 //@ compile-flags: -Clto -Zvirtual-function-elimination //@ only-x86_64 pub fn main() { _ = Box::new(()) as Box<dyn Send>; } </del>

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
UnsafeBlock(ast::NodeId), } <del> struct Context { /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, } </del> fn type_is_unsafe_function(ty: ty::t) -> bool { match ty::get(ty).sty { <del> ty_bare_fn(ref f) => f.purity == unsafe_fn, ty_closure(ref f) => f.purity == unsafe_fn, </del> <ins> ty::ty_bare_fn(ref f) => f.purity == ast::unsafe_fn, ty::ty_closure(ref f) => f.purity == ast::unsafe_fn, </ins> _ => false, } } struct EffectCheckVisitor { tcx: ty::ctxt, <del> context: @mut Context, </del> <ins> /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, </ins> } impl EffectCheckVisitor { fn require_unsafe(&mut self, span: Span, description: &str) { <del> match self.context.unsafe_context { </del> <ins> match self.unsafe_context { </ins> SafeContext => { // Report an error. self.tcx.sess.span_err(span,

Discussion:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)
Change:
<ins> fn main() { // foo must be used. foo(); } // For this test to operate correctly, foo's body must start on exactly the same // line and column and have the exact same length in bytes in a.rs and b.rs. In // a.rs, the body must end on a line number which does not exist in b.rs. // Basically, avoid modifying this file, including adding or removing whitespace! fn foo() { assert_eq!(1, 1); } </ins>

Discussion:
I encountered an ICE today. Below you find the backtrace of running . I ran afterwards and the ICE vanished, so it seams to be connected to incremental compilation. If required I can attach the full project including the build directories, as I zipped it after the ICE.
If possible, we would most of all appreciate a reproducer that works on the playground (this will facilitate fixing the bug faster) but if that's not possible a link to the zip would be good also.
Sorry, I didn't had enough time for it lately. Are there any guidelines how to track down such an incremental compilation error? Unfortunately I cannot recall the steps I've done. I've minimized the code in such a way, that removing any more causes the ICE to vanish. I'll attach this Zip-archive, so somebody else might have a look. Note, that this is not yet a MCVE.
any luck so far? The code looks good, now you have to recall what you did (rename a variable, changed something from a struct to a trait? Deleted members of a struct? Added functions? Removed them?) I know it's hard to debug incremental bugs (I encountered two so far). Any chance that you can tell us, what you did between , and the second ?
Unfortunately no. I tried to recall things, that I've done at this point, but any change I made either also ICEs or compiles fine. I've tried to reproduce this by writing the same code again, but obviously I write it a little bit different now, so I cannot get it to crash. Are there any tips how to deal with those incremental compilation crashes? Trying to reproduce like I'm doing it now is poking around in the dark.
As said, it could be anything ^^ Here are some examples I've seen so far in the wild:
Okay, thanks, I'll have a look at the linked issues :smiley:
Today I encountered the same ICE with "the len is 1077 but the index is 1077". I was writing and running some integration tests; it involved a serialization format (with Serde). I changed an array constant in a test case, then the panic occurred. When I changed it again, the ICE went away, and then I couldn't reproduce it anymore, not even with the value that seems to have caused it in the first place.

We've got the same bug with the len number of 30, not on my machine but on (the CI account isn't mine). If you guys know how to do the magic to pull the build artifacts from travis - you're welcome, CI account's owner seems willing to cooperate
Maybe the commit succession can be of interest to investigate the bug.
I got this same panic, and it also went away after a clean build.
Another one here, looks like the same problem and it also went away for now after .
Change:
= note: see issue #55467 <https://github.com/rust-lang/rust/issues/55467> for more information = help: add `#![feature(non_ascii_idents)]` to the crate attributes to enable <del> error: aborting due to 13 previous errors </del> <ins> error: aborting due to 14 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

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:
// memory between these pointers must be accessible. Note that we do not require the // pointers to be properly aligned (unlike a read/write operation). let min_ptr = if offset_bytes >= 0 { ptr } else { offset_ptr }; <del> let size: u64 = uabs(offset_bytes); </del> <ins> let size = offset_bytes.unsigned_abs(); </ins> // This call handles checking for integer/NULL pointers. self.memory.check_ptr_access_align( min_ptr,

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
<ins> #![feature(intrinsics)] extern "C" { pub static FOO: extern "rust-intrinsic" fn(); } fn main() { FOO() //~ ERROR: use of extern static is unsafe } </ins>

Discussion:
When learning async/await feature I was struggling with running multiple tasks simultaneously. Loop causes compiler to crash Github Action crash output: I expected to see this happen: Error message if something goes wrong. Instead, this happened: Compiler crashed Crash happens on macOS rustc 1.40 / Linux rustc 1.40 / Linux rustc 1.39 ( github actions ) :
If you could provide an example that ICEs in e.g. the playground that would be helpful towards fixing the issue. :)
Provided example is pretty small, but it is dependent on tokio and actix-web. I do not know how to create such an example in playground, I do know know how I can replace async tokio::sync::mpsc with standard library which does not have async alternative as far as i know. I have tried to simplify code but then crash disappear. Just putting everything into one file and crash is gone, code wont compile and reasonable errors show up.
Visiting from triage.. we decided that as the first step we should reduce this reproducer to a more self-contained one.
Can repro. Will try and min.
Reduced version so far is here:
This no longer ICEs on the latest nightly.
Let's see if we can shrink further so that we can add a test. 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
I’ve reduced it quite a bit. Down to dependencies on only. Appears to need 2 crates.

I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.