jiebi/CodeConvo huggingface dataset:
This code here has a potential issue: If the Box has a custom allocator, then that will not be checked at all. So whatever is used for, it ignores anything stored in custom allocators. It seems like this is just for a lint, so this is probably not critical, but I guess should still be fixed. Cc -- not sure whom else to ping for coroutine state machine transform things?
Cc (also a regular occurrence in this file's )
Lol sorry, I thought I had clicked enter on a comment but I must've not. Let me rewrite it. Yeah, this is approximately the level of urgency you determined. This code exists for an unstable lint, . I don't expect people to be writing , but technically they could.
I'm seeing an internal compiler error on the following input (found by ): The error happens on stable, beta, and nightly.
The only early return I see that doesn't emit is here:
Applying the most obvious patch, I get the following non-ICE output: The "expected , found " bit doesn't seem quite right. :slightlysmilingface:
is an unfortunate side effect of the unmatched delimiter recovery logic not accounting for s. Submit a PR with this patch to fix this ICE as fixing the slightly misleading message will require a much larger (unrelated) change.
I'll toss one up after I finish running the test suite. One thing: I'm not sure how to annotate the test. It looks like there's four errors that all point to EOF, but whatever I try to write, only one of them gets recognized as referring to that line.
this is what I did
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)', 'error: internal compiler error: unexpected body ty: {type error} phase Runtime(PostCleanup)' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
cc :D (note you'll need which was merged 10 minutes ago ^^ )
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' 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: [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mir_borrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to
So invalidated the assumption that the final stage is stage2, but [this piece of code][] still thought so, so the save-analysis data is never generated. This enraged the bots. Let's polish rustbuild with some more <3 so that we could have a fresh nightly for a nice New Year gift to everyone... []:
BTW the failure on the win32 beta bot (ouch!) is not related to this. It's most likely a Windows hiccup.
Ahhhh big failure of mine. I'm focusing on the generation part (the envvar) and forgot to touch the logic too, and the bots are as red as yesterday (facepalm). Trying to hit the 2017-01-02 nightly instead...
Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.
I noticed this scrolling by while "Building stage0 compiler artifacts" today: Optimistically flagging E-easy
I'd like to work on this, how can I fix? make rustc use one version(maybe v0.6.1)?
You will need to look into each dependency that depends on (by searching through ), check if they have a newer version that depends on new , and finally use to upgrade those crates.
Thanks! When I checked, it seems each rand version is used.
Yeah, it's natural that they are all used, and you could try to eliminate those crates using old by upgrading or refactoring. That said, there isn't much drawback with an older , so in that case this issue can be just closed.
Oh, I'm sorry, I misunderstood. Hmmm, I think we don't have to fix this quickly and this may be a catalyst for a newbie like me to contribute, so I leave this, okay?
but one could argue that it will lower the time to compile so it's worth to fix IMHO ;)
Uh, would it be better to fix?
Disclaimer: I'm not a core member, but IMHO this is worth fixing. Also scottmcm who is a core member opened this issue, so I guess you're good to go and fix that issue :)
Okay, I want to try to fix. For instance, depends on , how can I update or refactor this?
That's one thing you can't edit, because rand is a dependency of crossbeam-channel here, so the crate crossbeam-channel needs to update its dependecy (maybe it already did and you just need to update crossbeam-channel itself)?
For future reference, running  from is an easy way to identify the source of all duplicates.
Thanks ! I got this tree(). I updated , but is latest and depends on (). What should I do?
I'm not on compiler (or core), so don't take my word on this one :slightlysmilingface: It looks like upstream rayon needs 0.5, so you could consider making a PR to upgrade it to 0.6. (Maybe .) Also, it seems that , so they'd probably appreciate a PR to upgrade it to newer upstream.
Current rayon only uses rand as a dev-dependency, since rayon-rs/rayon.
That wouldn't show up in here at all, if rustc-rayon follows suit.
So the latest versions are and , but is used in this repository. They come from . Maybe those dependencies should be updated or made optional?
It looks like this was fixed in PR and merged by bors. Should this issue be closed now?
There are still 3 versions of rand in use:
will remove rand 0.5, I can get rid of 0.4 anytime but there are many PRs modifying right now.
Update: is used by , and (via ).
That's with -- only uses as a dev-dependency.
I didn't check now, but at some point was using an old version of a custom fork of .
has rebased since then, so it already reflects that dependency change.
I tried to fix a part of this in , but it didn't come out as planned. There is dependency and license whitelist that needs to be updated. I think just running leaves only one usage of via and (which can be updated). But then there is the licensing story, and it's not very clear to me which dependencies are used by the tools, and which by the compiler.
Last time I checked and were the only thing preventing of , otherwise I'd fix it already. We are working on removing it but it's blocked on releasing new version of .
I think goes away after a , so that one might be easy to fix. I don't know how dependencies are updated across the repository. Is it just that most of them are for the tools, not for and ? Does somebody run from time to time? And why does the license check fail on bors on my PR, but not on Travis or on my computer?
So released new version since. Correct, dependencies of everything that is created by are tracked by single . Dependencies are often updated separately as needed because upgrading everything at once is likely to break something and it's easier to find what is wrong when you change like 5 dependencies instead of 50. I think it should error when you run .
Also you can run the same image that found the error ( in this case) by using these steps
I tried this code: I expected to see this happen: generates a toml file with the contents Instead, this happened: HEAD is branched from . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Relevant code:
claim
Error: Parsing assign command in failed: ...' claim' ' :)'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have a PR ready but I need to wait for to get merged since that PR was and creating a new branch now doesn't help
You can run (replace with the name of the rust-lang remote), then run . In the future, take the habit of always having your branch fast-forward able, it will avoid you hassles with the GitHub UI.
That worked for me, Thank you so much!
Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 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: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .
I was playing around with some code which can be found and is attached below. When I click on output I get the following output: I don't have a rust installation locally right now, so I cannot create the backtrace. I'll add it later today. The code which triggers this:
Stack trace: (There is no ICE with (nothing generated either due to type error). Perhaps playpen should use instead.)
You can get backtrace on playpen here: !
Looks like this has been fixed recently
I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:
Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :
<!-- 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. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- 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</detailsI just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
<!-- 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. --Compiles with replaced for <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
, anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new:
Update: this is the tracking issue for: is both unstable and deprecated, it should be removed. There is currently no way to tell whether there is any data buffered inside a BufReader. This is unfortunate because it means that an application has no way to know whether calls to read() and fillbuffer() will return instantly or trigger a potentially expensive call to the underlying Reader. I propose adding an is_empty() method to BufReader to fill this gap.
now that has been merged, I'm guessing this should get the label?
What's left for this to stabilize? I'm parsing bytes from a to MsgPack using . The function will stop parsing once a valid MsgPack value has been found. But in my application the parsing should fail if the buffer hasn't been consumed completely. Checking would probably be the cleanest way to do so.
the method proposed in may also be useful for that purpose, though that may take even longer to land.
This is the tracking issue for: Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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.
This seems fine to stabilize, but it seems like it'd be more useful to know how many bytes are buffered, rather than just that there are some number of bytes.
Why not both? Slices have even though it’s somewhat redundant with .
For sure. Would it be reasonable to try to squeeze that into this stabilization?
Sounds ok to me, though we should probably (re)start FCP after the implementation is merged.
Naming wise, I don't think fits since that seems to me like it'd refer to the length of the entire reader rather than just the current buffered data (similarly is a bit confusing). How about and ?
Agreed. Sounds good to me.
Alternatively, we could add to just return the buffer, which is also a thing people want separately from this issue. At that point seems not much worse than so we could have one method instead of three.
adds and deprecates .
:bell: This is now entering its final comment period, as per the . :bell:
With alternative (and IMO better) proposal just introduced, should this still be going into its final comment period?
fcp cancel Let’s start again after has landed.
proposal cancelled.
We should likely also add a method to for consistency?
That can't be done backwards compatibly.
why not? It's just a , right? Just like .
Oh derp I somehow read that as .
Haha, no worries. Is there even a trait?
No there isn't _Off of the topic of me needing more caffeine, it definitely seems reasonable to add to , and fold it into the same feature gate as 's.
It has been a while since landed. Is this ready to stabilize?
is implemented, but discussed above is not. (I’ve updated the issue’s description with the current status.)
Wait, we aren't proposing to stabilize the (already deprecated) is_empty method are we?
No, sorry I didn’t clarify. An API marked both unstable and deprecated is to be removed (after something like a couple release cycles of deprecation period, which we’re at in this case).
I'm excited to see that this is so close to landing. Is this still waiting on an implementation of ? Would it be possible to track that feature separately to unblock this one?
Bump. Is there anything else blocking stabilization?
Is there any particular reason not to add to ? It seems like a useful enough general-purpose API ("get me however many bytes you can easily give me"), and I found myself looking for such a method while working on parser tooling. Individual implementations could make stricter guarantees about the lower bounds, of which "at least the unconsumed fraction of the last " would be a common one.
Yeah, this has been a while. is this ready for a vote to stabilize?
This issue seems to have been stuck in a strange limbo state for quite a while now. Pinging more people the rfcbot mentioned...
Sorry we dropped the ball here. This is now one method on the and structs. fcp 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.