jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: bounds on generic parameters are not enforced in type aliases --> $DIR/issue-67690-type-alias-bound-diagnostic-crash.rs:5:15 | LL | pub type T<P: Send + Send + Send> = P; |               ^^^^   ^^^^   ^^^^ | = note: `#[warn(type_alias_bounds)]` on by default help: the bound will not be checked when the type alias is used, and should be removed | LL | pub type T<P> = P; |            -- </ins>

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
/// ``` pub fn is_unicast_global(&self) -> bool { !self.is_multicast() <del> && !self.is_loopback() && !self.is_unicast_link_local() && !self.is_unicast_site_local() && !self.is_unique_local() && !self.is_unspecified() && !self.is_documentation() </del> <ins> && !self.is_loopback() && !self.is_unicast_link_local() && !self.is_unique_local() && !self.is_unspecified() && !self.is_documentation() </ins> } /// Returns the address's multicast scope if the address is multicast.

Discussion:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed
Change:
} fn from_ident(ident: Ident) -> Segment { <del> Segment { ident, id: None } </del> <ins> Segment { ident, id: None, has_generic_args: false } </ins> } fn names_to_string(segments: &[Segment]) -> String {

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
use rustc_ast::token::{self, DelimToken, Nonterminal, Token, TokenKind}; use rustc_ast::tokenstream::{self, LazyTokenStream, TokenStream, TokenTree}; use rustc_ast_pretty::pprust; <ins> use rustc_data_structures::fx::FxHashSet; </ins> use rustc_data_structures::sync::Lrc; use rustc_errors::{Diagnostic, FatalError, Level, PResult}; use rustc_session::parse::ParseSess; use rustc_span::{symbol::kw, FileName, SourceFile, Span, DUMMY_SP}; use smallvec::SmallVec; <ins> use std::cell::RefCell; </ins> use std::mem; use std::path::Path; use std::str;

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --We have a library that compiles fine on 1.47.0 but after uggrading to 1.48.0 the compilation hangs. This code-snippet above is reduced from the original code as much as I can. I'm having problems understanding exactly where the problem is coming from and any further modifications to reduce it haven't worked. It uses the "paste" crate, and I've tried a few different versions including the latest one but it doesn't make a difference . I've been building it with at 1.47.0 and 1.48.0 to reproduce the issue which I got just by running doesn't work on works on </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Some quick notes as I find them: This reproduces on just a cargo check, so has nothing to do with codegen (unsurprising) Compilation time scales by a little more than 2x for each additional number (going from 0 to 20 took 11 seconds, 21 took 26, 22 took 1 min 5) Given that I don't think this is a hard hang per se, just a really really long running compilation Definitely something in macro expansion, compiling the post- code is instant Reproduces on current nightly. -Zself-profile shows all the time is spent in . Unfortunately I don't have a debug build of rustc handy, but I imagine slapping a profiler on one should make the issue fairly obvious. I'd recommend cutting the provided example down from 64 to 20 though.

searched nightlies: from nightly-2020-08-24 to nightly-2020-10-03 regressed nightly: nightly-2020-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like
If it helps, this crate was exploring some ideas related to the crate
Assigning and removing as in the prioritization working group.
This is caused by some of the extra logic I in to ensure that we don't throw out the captured unnecessarily. I'm looking into improving the performance. In the longer term, this will be solved by getting rid of the pretty-print/retokenize hack entirely.
Change:
<ins> error: can't mark as unstable using an already stable feature --> $DIR/unstable-attribute-rejects-already-stable-features.rs:6:1 | LL | #[unstable(feature = "arbitrary_enum_discriminant", issue = "42")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this feature is already stable LL | #[rustc_const_unstable(feature = "arbitrary_enum_discriminant", issue = "42")] LL | const fn my_fun() {} | -------------------- the stability attribute annotates this item | help: consider removing the attribute --> $DIR/unstable-attribute-rejects-already-stable-features.rs:6:1 | LL | #[unstable(feature = "arbitrary_enum_discriminant", issue = "42")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: can't mark as unstable using an already stable feature --> $DIR/unstable-attribute-rejects-already-stable-features.rs:7:1 | LL | #[rustc_const_unstable(feature = "arbitrary_enum_discriminant", issue = "42")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this feature is already stable LL | const fn my_fun() {} | -------------------- the stability attribute annotates this item | help: consider removing the attribute --> $DIR/unstable-attribute-rejects-already-stable-features.rs:7:1 | LL | #[rustc_const_unstable(feature = "arbitrary_enum_discriminant", issue = "42")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.
Change:
desc { "traits in scope for documentation links for a module" } separate_provide_extern } <ins> /// Used in `super_combine_consts` to ICE if the type of the two consts are definitely not going to end up being /// equal to eachother. This might return `Ok` even if the types are unequal, but will never return `Err` if /// the types might be equal. query check_tys_might_be_eq(arg: Canonical<'tcx, (ty::ParamEnv<'tcx>, Ty<'tcx>, Ty<'tcx>)>) -> Result<(), NoSolution> { desc { "check whether two const param are definitely not equal to eachother"} } </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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
// // If the LLVM is coming from ourselves (just from CI) though, we // still want to install it, as it otherwise won't be available. <del> return; </del> <ins> return false; </ins> } }

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
cat "$TOOLSTATE_FILE" echo <ins> # This function checks that if a tool's submodule changed, the tool's state must improve </ins> verify_status() { echo "Verifying status of $1..." if echo "$CHANGED_FILES" | grep -q "^M[[:blank:]]$2$"; then

Discussion:
I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.
Change:
// `PartialEq::eq` on it. return Err(FallbackToConstRef); } <ins> ty::FnDef(..) => { self.saw_const_match_error.set(true); tcx.sess.emit_err(InvalidPattern { span, non_sm_ty: ty }); PatKind::Wild } </ins> ty::Adt(adt_def, _) if !self.type_marked_structural(ty) => { debug!("adt_def {:?} has !type_marked_structural for cv.ty: {:?}", adt_def, ty,); self.saw_const_match_error.set(true);

Discussion:
(note: this is very similar to but it does appear to be a different ICE) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +requires-nightly +F-inlineconstpat +requires-incomplete-features

<!-- 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 label +requires-nightly +F-inlineconstpat +requires-incomplete-features
Change:
/// /// This trait allows for partial equality, for types that do not have a full /// equivalence relation. For example, in floating point numbers `NaN != NaN`, <del> /// so floating point types implement `PartialEq` but not [`Eq`]. </del> <ins> /// so floating point types implement `PartialEq` but not [`Eq`](Eq). </ins> /// /// Formally, the equality must be (for all `a`, `b` and `c`): ///

Discussion:
In the documentation for [][1], you will find the following: The link on this page is not actually a link to the trait, but a link to the method on the same page. The link is written as [] with an []: PartialEq::eq in the same doc-comment, so I am unsure whether this should be considered an issue in the documentation, or in rustdoc. [1]: [2]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
impl Stderr { pub const fn new() -> Stderr { <del> Stderr </del> <ins> Stderr { incomplete_utf8: IncompleteUtf8::new() } </ins> } } impl io::Write for Stderr { fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> write(c::STD_ERROR_HANDLE, buf) </del> <ins> write(c::STD_ERROR_HANDLE, buf, &mut self.incomplete_utf8) </ins> } fn flush(&mut self) -> io::Result<()> {

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 code: I expected to see this happen: Program does not panic. Instead, this happened: Program panics with the error . <!-- 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</summary<p</p</detailsTo clarify: This problem occurs with all trait implementations that don't override the default implementation, e.g. with this simple DelegatingWrite:
I see two distinct possibilites to resolve this: 1) Treat incomplete s not ending on a codepoint boundary as a bug and fix that in the stdlib. Also clarify in the docs that indivual calls must be passed complete UTF-8 sequences if a Windows terminal is attached. 2) In the vain of "Be liberal in what you accept" handle incomplete UTF-8 passed in via calls appropriately, as long as the sequence is completed properly in the next call(s).
Hm, so this is ultimately a bug in the buffer uses? It attempts to write 1024 bytes but only 1023 bytes can written in the first OS call. It then has a leftover byte, which I guess it tries to write by itself thus causing this error?
The logic which errors if incomplete UTF-8 is passed in at index 0 is in the std lib at . That is where the error message comes from. As far as I can see the stdio buffer implementation (in stable, it is in , apparently currently being revamped) can not know of the requirement that only complete UTF-8 may be written to the underlying Windows terminal so I think that it should be encapsulated in by just accepting and buffering incomplete UTF-8 when necessary.
I mean, a generic buffer can attempt to avoid small writes (say, less than 16 bytes) by copying those left over bytes to the front of the buffer and waiting for either another to refill the buffer or a to empty it. But I see what you mean. Introducing a small buffer to windows/stdio would fix the problem.
Change:
let args = &[ "compiletest", "--mode=ui", <ins> "--suite=ui", </ins> "--compile-lib-path=", "--run-lib-path=", "--rustc-path=",

Discussion:
When compiletest fails, it prints an error summary like this at the end: However, there is one very important bit of information that I cannot gleam from this information: what are the host and target architectures that were tested! Figuring this out requires scrolling up quite a bit to where this test beings (and carefully not scrolling up too far because then one might look at the wrong test). See for an example where this confused people. I have also been confused by this multiple times in the past, e.g. using the name of the CI runner to incorrectly deduce what the architecture(s) are (and not realizing that some of our runners run tests for quite a few different targets). So I think in case of a failure, that summary at the end should repeat the important information that is printed at the top of the test run:
Cc
And also it would be nice if when it ignored a test because it was the wrong platform, it showed some indication of that, because otherwise it looks like it ran the test and it passed. Perhaps show a question mark ()? (We already use for tests that were ignored because they were already run and passed.)
AFAIK should already be used for all kinds of "ignored", including directives.
Turns out these messages are printed by bootstrap, not compiletest: However, detecting failures and exiting is done a few layers deeper: In case of failure, never returns or unwinds (except if fail-fast is off). I am not sure how to best adjust this to print an error before exiting (or to always print an error after the process finished, whether it succeeded or failed). any advice? If we just want this to happen when fail-fast is off, that would be easy, but I am not sure if that ever applies.
Change:
impl NonCamelCaseTypes { fn check_case(&self, cx: &LateContext, sort: &str, name: ast::Name, span: Span) { <ins> fn char_has_case(c: char) -> bool { c.is_lowercase() || c.is_uppercase() } </ins> fn is_camel_case(name: ast::Name) -> bool { let name = name.as_str(); if name.is_empty() {

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"?