jiebi/CodeConvo huggingface dataset:
Change:
check::CargoMiri, check::MiroptTestTools, check::Rls, <del> check::RustAnalyzer, </del> check::Rustfmt, <ins> check::RustAnalyzer, </ins> check::Bootstrap ), Kind::Test => describe!(

Discussion:
Sometimes when changing compiler internals, I run to make sure I didn't break tools and codegen backends. This also checks rust-analyzer by default, which is not very useful, I cannot break that. If we want to keep that, it would at least be useful to put it last so I can Ctrl-C out of it. Currently, rustfmt is checked after rust-analyzer. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
mentoring instructions: switch the order of these two lines:
points out that Cargo also isn't checked by default, so for consistency it would be nice for RustAnalyzer not to be either:
claim
Change:
fn check_type(&mut self, x: &'a Type) { match x { <del> Type::ResolvedPath(path) => self.check_path(path, PathKind::StructEnumUnion), </del> <ins> Type::ResolvedPath(path) => self.check_path(path, PathKind::Type), </ins> Type::DynTrait(dyn_trait) => self.check_dyn_trait(dyn_trait), Type::Generic(_) => {} Type::Primitive(_) => {}

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)
Change:
<del> Subproject commit 28f2e5b17a9a4c33a810dffda8eaaf55a1b8b70d </del> <ins> Subproject commit 7c06679f93df53f83bbf61b197f2e5c39f5d7633 </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! cc the PR reviewer, and -- nominating for prioritization.
Miri fix: I'd like to see landing before updating the submodule, as that will break Miri again.
This was automatically nominated by rust-highfive. Based on past discussion with about miri-prioritization, tagging as P-medium.
Change:
let lower_sub = |this: &mut Self| sub.as_ref().map(|s| this.lower_pat(&*s)); break self.lower_pat_ident(pattern, binding_mode, ident, lower_sub); } <del> PatKind::Lit(ref e) => break hir::PatKind::Lit(self.lower_expr(e)), </del> <ins> PatKind::Lit(ref e) => { break hir::PatKind::Lit(self.lower_expr_within_pat(e, false)); } </ins> PatKind::TupleStruct(ref qself, ref path, ref pats) => { let qpath = self.lower_qpath( pattern.id,

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. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- 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. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
} ty::Predicate::WellFormed(ty) => { <del> Ok(ty::wf::obligations(selcx.infcx(), obligation.cause.body_id, ty, obligation.cause.span)) </del> <ins> match ty::wf::obligations(selcx.infcx(), obligation.cause.body_id, ty, obligation.cause.span) { None => { pending_obligation.stalled_on = vec![ty]; Ok(None) } s => Ok(s) } </ins> } } }

Discussion:
This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).
Change:
(&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => tk == tk2, (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && <del> dl.stream().trees().zip(dl2.stream().trees()).all(|(tt, tt2)| tt.eq_unspanned(&tt2)) </del> <ins> dl.stream().eq_unspanned(&dl2.stream()) </ins> } (_, _) => false, }

Discussion:
I ran across a very curious case today... Given this procedural macro: and this expansion: when compiled I get: which is quite curious! -- er, just wrong thinking here cc cc cc
Seems similar to how also causes an inconsistency.
Ok I think I see what's going on here. This has to do with introduced in Basically I think this boils down to , we fundamentally cannot losslessly tokenize an AST item into a list of tokens to hand to a procedural macro. What's happening here is that all the tokens of the are saved off in the parser. This is the original source token stream which produced the struct. Later on when we tokenize the struct to hand off to a procedural macro we will use this cached token stream, if available, and tokenize it out and return it. When stringifying, however, we use the actual AST node itself (the source of truth). The bug is that cfg processing does indeed happen before the procedural macro runs. The cfg processing is modifying the AST item's internal fields but it's not invalidating the cached token stream or modifying it. Hence when the procedural macro runs the cached token stream is invalid wrt the internal state of the AST node, causing two different results to come out depending on how you look at it. Possible solutions here are: the cached list of tokens if the AST node is modified. This seems tricky to get right, are there other locations where a modification can happen? implemented , but holy cow that's a lot of work. the two results of tokenization (stringify + parse and the tokens themselves) and return the string one if they differ. None of them seem like great solutions :(
Change:
/// current length. The allocator may reserve more space to speculatively /// avoid frequent allocations. After calling `try_reserve`, capacity will be /// greater than or equal to `self.len() + additional` if it returns <del> /// `Ok(())`. Does nothing if capacity is already sufficient. </del> <ins> /// `Ok(())`. Does nothing if capacity is already sufficient. This method /// preserves the contents even if an error occurs. </ins> /// /// # Errors ///

Discussion:
Any methods of container types (12 in Rust 1,62.1, including duplicated ones in ), and maybe corresponding methods. - - - - ... and corresponding methods in . Documentations for describes "If the capacity overflows, or the allocator reports a failure, then an error is returned.". However, it does not give any guarantees about whether the content is preserved or not on that error. This guarantee (or absence of the guarantee) should be explicitly described.
At least for (and -based things like ) it's obvious to guarantee that, so we might as well. (Thank you, Rust, for insisting on move-is- so we don't have the "what if the move constructor panics" problems like C++.) I think it'll need to be to hashbrown before we can consider promising it for /, through -- there's no guarantee in <https://rust-
Modulo needing to add it in hashbrown, shall we see if we have consensus to say that failures preserve the current contents? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Please feel free to post a PR for this.
Created a PR for this.
Change:
// Check for infer types because cases like `Option<{integer}>` would // panic otherwise. if !expr_ty.has_infer_types() <ins> && !ty.has_infer_types() </ins> && fcx.tcx.type_implements_trait(( from_trait, ty,

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. --When trying to cast a slice, I encountered an ICE in nightly rust. It works in at least two different nightly versions: rustc 1.46.0-nightly ( 2020-06-26) and rustc 1.46.0-nightly ( 2020-06-29). I haven't tested any other versions. In stable rust (1.44.1), no ICE occurs. A minimal example to reproduce this is here: I expected the following result: Instead, I encountered an ICE. From the little testing I have done, it seems to require slices for the ICE to occur. Replacing the slices with structs causes the ICE to disappear. I got the ICE to work with the following two versions: : and It might work with earlier versions of nightly as well, but I haven't checked this. It does not occur with the latest stable version (1.44.1). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Let’s try to find the culprit for this. 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-06-19 to nightly-2020-06-27 regressed nightly: nightly-2020-06-20 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 modify labels: -E-needs-bisection
Probably cc
Prioritized as as per .
Change:
<del> Subproject commit 477e7285b12f876ad105188cfcfc8adda7dc29aa </del> <ins> Subproject commit fd949f3034f8a422ecfffa889c2823485dde4bdd </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --rust-num/num-bigint The code prints the output below and exits successfully. The code prints the output below and panics. <!-- 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. --:
Here's some reproduction on Godbolt. The problem seems unrelated to i64 and it's entirely the u64 -f32 conversion that's buggy. The fact that we use the floating point numbers as some sort of address makes it seem like we are loading the value from a lookup table and there might be a bug in Windows' table:
Took me way too long, but I figured it out. The fact that FPU instructions are used means that it runs into problems with the FPU accuracy. By default the control word is set to 0x27f on Windows and 0x37f on Linux. In particular the 0x3 vs 0x2 is the precision control setting of the FPU. 01 = Not used 10 = 53 bits (REAL8) 11 = 64 bits (REAL10) So on Windows it's in 53-bits mode whereas on Linux it's in 64-bits mode. Running the following code therefore fixes the problem on Windows: This probably is an LLVM bug where LLVM assumes the FPU is configured like on Linux instead of like on Windows. MSVC for example just emits a call to instead, which is probably the correct thing to do. (Also it's a little surprising to me the FPU is used at all, when i686 afaik even has SSE2 available by default).
The function that lowers the uint to float cast is in . There's basically a bunch of checks to generate shorter versions if various conditions are met, but all of them fail and it has to resort to using the FPU. There actually is one case in there where they treat Windows differently, I'm guessing something similar can be done to not fall into the FPU default case here as well. In particular because both SSE2 and a builtin function that does exactly this cast exist.
I tested it with some other code and thought it was resolved.
This was patched upstream (thanks icedrocket!)

but it seems like they reverted the patch, as unfortunately it broke Chrome's build: I don't know if it is more profitable to work around this on our end by emitting the relevant call? It looks like there's an intention to use another fix:
A new fix has been commited to upstream: llvm/llvm-project
Change:
use crate::boxed::Box; use crate::vec::Vec; <ins> #[unstable(feature = "array_chunks", issue = "74985")] pub use core::slice::ArrayChunks; </ins> #[stable(feature = "slice_get_slice", since = "1.28.0")] pub use core::slice::SliceIndex; #[stable(feature = "from_ref", since = "1.28.0")]

Discussion:
In the stdlib I'd like an iterator like chunksexact that yields fixed-sized arrays, using a const usize argument (mostly useful for short arrays). .chunksexactct::<3() .map( a + b + c) Those arrays could allow better optimizations and also better pattern matching. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This also applies to the method on slices.
We should actually be able to implement this and test it out unstably now.
Im willing to give this a shot in the weekend and next week!
assign
So, a simple PoC fails to compile horribly <details<summary<strongBacktrace</strong</summary<p</p</details
Notice that a freestanding function does work:
The more I go into this, the more obstacles I stumble upon. Below a list of all ICE's I encountered:
Keep going on, those bugs/limitations are worth fixing anyway :)
to_array() could be a new function related to take(), it collects the first N items of an iterator into an array of length given as const generic argument (it panics if the iterator isn't long enough). Usable like this (using iterate() from itertools):
EDIT: This is already PR'd:
We need a good built-in static_assert that works with constant generics too :)
Change:
// the string "false". Now it is disabled by absence of the attribute. to_add.push(llvm::CreateAttrStringValue(cx.llcx, "branch-target-enforcement", "false")); } <del> } else if llvm_util::get_version() >= (19, 0, 0) { // For non-naked functions, set branch protection attributes on aarch64. if let Some(BranchProtection { bti, pac_ret }) = cx.sess().opts.unstable_opts.branch_protection { assert!(cx.sess().target.arch == "aarch64"); if bti { to_add.push(llvm::CreateAttrString(cx.llcx, "branch-target-enforcement")); } if let Some(PacRet { leaf, key }) = pac_ret { to_add.push(llvm::CreateAttrStringValue( cx.llcx, "sign-return-address", if leaf { "all" } else { "non-leaf" }, )); to_add.push(llvm::CreateAttrStringValue( cx.llcx, "sign-return-address-key", if key == PAuthKey::A { "a_key" } else { "b_key" }, )); </del> <ins> } else { // Do not set sanitizer attributes for naked functions. to_add.extend(sanitize_attrs(cx, codegen_fn_attrs.no_sanitize)); if llvm_util::get_version() >= (19, 0, 0) { // For non-naked functions, set branch protection attributes on aarch64. if let Some(BranchProtection { bti, pac_ret }) = cx.sess().opts.unstable_opts.branch_protection { assert!(cx.sess().target.arch == "aarch64"); if bti { to_add.push(llvm::CreateAttrString(cx.llcx, "branch-target-enforcement")); } if let Some(PacRet { leaf, key }) = pac_ret { to_add.push(llvm::CreateAttrStringValue( cx.llcx, "sign-return-address", if leaf { "all" } else { "non-leaf" }, )); to_add.push(llvm::CreateAttrStringValue( cx.llcx, "sign-return-address-key", if key == PAuthKey::A { "a_key" } else { "b_key" }, )); } </ins> } } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this : And compiled it with . I expected to see this happen: The compiler should generate a function which only contains the instruction. Instead, this happened: The compiler crashes with . <!-- 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. --: As requested in
This is an LLVM assertion
It was noted in that this comes from sanitizer annotations being to naked functions. Seems like we might not want to do that? Cc
Almost certainly, but is not supposed to be used in places where user input can cause it to be reached.
Reported at
To clarify, the fix that landed is just to make this an IR verification failure rather than a backend crash. The underlying issue with the kasan + naked combination still needs to be fixed.
Should we file an issue upstream to handle this in sanitizers as well, or is there one already opened?
Change:
"use soft float ABI (*eabihf targets only) (default: no)"), target_cpu: Option<String> = (None, parse_opt_string, [TRACKED], "select target processor (`rustc --print target-cpus` for details)"), <del> target_feature: String = (String::new(), parse_string, [TRACKED], </del> <ins> target_feature: String = (String::new(), parse_target_feature, [TRACKED], </ins> "target specific attributes. (`rustc --print target-features` for details).  This feature is unsafe."),

Discussion:
I'm trying to pass multiple conditionally downstream. However, despite +/- for adding/removing a feature it appears only the last value takes effect.
FWIW, you can check for values without any test program like: $ rustc --print cfg -C target-feature=+avx2 -C target-feature=+fma $ rustc --print cfg -C target-feature=+avx2,+fma
I agree that it's a bug and will try to fix it.
Fixed in
Change:
self.expect(&token::CloseDelim(token::Bracket))?; let hi = self.prev_span; <del> (lo.to(hi), path, tokens, style) </del> <ins> let attr_sp = lo.to(hi); // Emit error if inner attribute is encountered and not permitted if style == ast::AttrStyle::Inner { if let InnerAttributeParsePolicy::NotPermitted { reason, saw_doc_comment, prev_attr_sp } = inner_parse_policy { let prev_attr_note = if saw_doc_comment { "previous doc comment" } else { "previous outer attribute" }; let mut diagnostic = self .diagnostic() .struct_span_err(attr_sp, reason); if let Some(prev_attr_sp) = prev_attr_sp { diagnostic .span_label(attr_sp, "not permitted following an outer attibute") .span_label(prev_attr_sp, prev_attr_note); } diagnostic .note("inner attributes, like `#![no_std]`, annotate the item  enclosing them, and are usually found at the beginning of  source files. Outer attributes, like `#[test]`, annotate the  item following them.") .emit() } } (attr_sp, path, tokens, style) </ins> } _ => { let token_str = self.this_token_to_string();

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
} Foo::<17>::value() <del> //~^ ERROR cannot call non-const fn </del> <ins> //[full]~^ ERROR cannot call non-const fn </ins> }]>; fn main() {}

Discussion:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim
Change:
* Flags should be orthogonal to each other. For example, if we'd have a json-emitting variant of multiple actions `foo` and `bar`, an additional --json flag is better than adding `--foo-json` and `--bar-json`. <del> * Always give options a long descriptive name, if only for better </del> <ins> * Always give options a long descriptive name, if only for more </ins> understandable compiler scripts. * The `--verbose` flag is for adding verbose information to `rustc` output when not compiling a program. For example, using it with the `--version` flag

Discussion:
. It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?