jiebi/CodeConvo huggingface dataset:
<!-- 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: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- 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. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.
Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in
After we started seeing the following compile failure: I repro'd this locally on but we have so we're fairly sure that it started with . Of the changes in that rollup is the only one that seemed to touch float stuff, but I'm not sure how adding some extra impls for and would break inference in this case.
cc is it possible that adding the the impls for / may have caused type inference regression here?
It must be, but I don't know why since wasn't touched. Also reproduced locally
When there is only one applicable impl it can guide inference, as soon as there are multiple it can't use those and instead goes to default-numeric-fallback which appears to be for floating point.
Correct.
Just coming to the same conclusion - the literal is getting guided to f32 on stable since that's the only type that fits the , but when there are more options it gets the default float literal type of f64
I'll put up a PR to remove these impls for now but what is the correct longer term fix? cc
label -needs-triage +A-inference +F-f16andf128
Race condition <img width="497" alt="image" src=""
I did not remove the feature label lol (it wasn't even in the list), welldone GitHub
Theoretically, type inference regressions are permitted as part of Rust's 1.0 stability guarantees. In practice, if the regressions are too bad, the changes usually get reverted and are subsequently blocked indefinitely iirc. However, we could make use of editions if the worst comes to the worst. See arrays & . I think we have something similar queued up for Rust 2024. On mobile, can't link.
I put a fix up at and opened to further discuss what we want to do here. Thanks for identifying this so quick!
if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.
that we caught it on. It's a pretty simple case (that type is just an type alias) and seems reasonable to break on an edition boundary (or even just on a release as long as there's a machine applicable suggestion to fix it).
Hi! I'm from the Bevy project.
Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that
This is a regression from the last couple of days. Looks like the compiler for something forever. Curiously, the run with completes successfully. I'll investigate in more detail. The list of tests: All of the tests are supposed to report errors.
Here's the backtrace:
Looks like this is caused by the recent unwinding changes. cc
GCC toolchain version on which this reproduced:
Does this happen with stage 1 rustc or stage 2 rustc?
Stage 1, e.g. I'll check stage 2 now.
( is confirmed to be the cause, removing .)
I have a pretty good idea of what the problem might be. I'm traveling right now but I'll try to have a PR up by tonight.
The issue doesn't reproduce with a stage 2 compiler. That's great news long term, but broken stage 1 still makes any compiler work involving testing hard.
I don't have a Windows machine to test on right now, but can you try marking and with in to see if that fixes the issue?
can you try marking and with in to see if that fixes the issue? It does! Thanks for a workaround.
<!-- 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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .
<!-- 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: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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.
introduced an ICE (integer overflow) in the error emitting code, that Miri runs into.
will fix the issue on 's end, which should automatically fix this one.
I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using Instead, this happened: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that.
claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:
For example: There are two issues here: actually helpful? All the code runs in the same thread with the same name, so it doesn't add any more info 's no space between the output and the header, so it's hard to read the logs. cc
I believe the crate, which is using, provides methods for and when constructing its layer, so it should be possible to turn this off. I believe the missing space is probably a bug in that crate, so I'd . It's possible this was the intended formatting, you'd probably need to ask to be sure.
Thanks, I'll do that :)
It should use . ( is the second field of .) While both instances are normally equal, they can differ after running the mir inliner. In that case the promoted will refer to the inlined function. modify labels: +A-mir +C-bug +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Can I give this a go? claim
Do you have any specific tests in mind I should add to check for the correct behaviour?
should be a test if the mir inliner would to inline . Somehow it doesn't though.
You might be running into this unfortunate check Try moving below .
Wow, that's hilarious. With just the changes suggested, the inlining still doesn't work properly, but doesn't seem to break any existing stuff. But I've just tried this and yeah, putting ret_slice below main has made the MIR inliner work.
This does inline, but somehow no assertion fires with current rustc. The printed MIR doesn't seem to show the the def_id from which the promoted originates, so I don't know what the problem is.
Unless I'm misunderstanding something, isn't this the correct behaviour? Both of those assertions are true, and swapping and around in the assertions correctly triggers an assertion failure.
I forgot that this problem was only with .
I got a working test:
Ah, that's a good test case. Yeah, that's definitely not the expected behaviour. While messing about with your example, I also managed to come across an ICE with this slightly shorter version: causes an ICE currently due to an internal index out of range. The good news is that the changes you suggested fixes both of these test cases. Good spot :) I'm putting up the PR now.
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself
Every Rust nightly as of approximately Jan 27, 2019 has to build my msp430 application due to assembler errors of the following form: This is due to in the LLVM backend that has been , but hasn't managed to propagate downstream to yet (thank you for the help). As I understand it, Rust only updates the LLVM backend occassionally, along with some patches; Is it possible to cherry pick this patch so that the msp430 backend works again before the next version bump? I would open this issue on the Rust LLVM fork, but Issues seems to be disabled for this repository...
I think we're generally speaking tracking trunk quite closely so should be feasible to bump here, cc
Friendly ping... has there been any update on this? I'd host my own copy of LLVM with the fix for the time being, but I doubt CI would like that...
pointed me to . Doesn't seem too difficult to follow; I think I should be able to do this myself, hopefully within the week, but at the very least soon :).
Rust now uses LLVM 9, could you try with recent nightly?
It was fun while it lasted. The transition to LLVM 9 causes a separate in my AT2XT repo<sup1</sup, so I'm unsure if we've regressed and this particular issue still applies, or if this is simply a totally separate error and the "r2" error was still fixed. Unfortunately, due to illness, I don't think I can work on this for about another week. Could you ping me again then please if I haven't responded at all. I'll just send another LLVM patch if necessary since I know how to do it now. (cc: Have you seen this? msp430 Rust still shouldn't be using LLVM's assembler for msp430 AFAIK. It may be ready for use however.)
You can try enabling it here but I have no idea if it works at all:
I'm looking into this for two evenings already, but still not found where the bug is. What I know so far: 1) Compiling with and both fail, which means it's probably not a issue, because doesn't need option. 2) Compiling with flag and then using to produce the assembly works fine. Which means the bug is specific to how Rust invokes LLVM.
I will keep debugging this and post here if I find something more.
For reference, the error: Which means that the MSP430 AsmParser cannot be found (even though it does exist). Looking at we see that we indeed fail to initialize it.
no so long ago the asm parser didn't exist on msp430, the inline assembly was just inserted as is into resulting assembly and everything was fine. What exactly have changed that now the asm parser is required? P.S. We can also get rid of option, since we can also produce object files now too.
The integrated assembler was enabled in , which is why it is now attempted to be used. (The option in rustc does not control this behavior.)
Reopening until there is confirmation that this is fixed...
Thank you for your work. There is still a bit more work to be done to get msp430 compiling again. The fix is involved/breaking, and and I (mainly me) will not be able to fix this until the week of August 11th.
I tested 1.38.0-nightly ( 2019-08-07) and can confirm that this issue has been resolved. I think you can close this now, thank you.
<!-- 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: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim
In , clippy CI , and I don't think that can be caused by my PR: <details</detailsCc
Seems same with my PR Did you try to rebase master for you branch? I resolved it in this way.
your problem was different. the problem Ralf is running into is
The error message and failed test case are both same with my failed CI in my new PR
gotcha - in that case the rebase probably didn't do anything except rerun ci - this only fails some of the time. https://rust- has a plausible explanation
See the discussion at https://rust- I believe this is an issue with ui_test.
This is causing lots of problems in CI, so I'm marking it as critical.
I'll leave it up to you on tracking what needs to be done to revert . It looks like you've been working on it in ui_test, but I'm not involved in clippy development, so I probably shouldn't be the one tracking/fixing things. However, if you have questions on the cargo side, let me know.
Thanks! After the next clippy sync (tomorrow) this should be fixed. On the ui_test side, the failure is now protected against being spurious and 100% reproducible. I'll ship that to miri soon to prevent the same thing from happening there.
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
When a process unexpectedly fails/succeeds, compiletest will often print a full dump of its stdout and stderr for diagnostic purposes. When this happens, calls into , which has special handling for lines starting with . It tries to parse the line as JSON in one of a few known compiler-specific formats, in order to replace it with a more human-friendly message. If the line doesn't match any of those formats (or isn't valid JSON), the extractor code will panic, instead of just printing the line as-is. This is awkward in cases where we actually wanted to print the line as-is anyway, because now the error messages are less helpful. label +A-compiletest
The obvious solution (just make it not panic) is complicated by the fact that is called in multiple places, so it's harder to know whether the error is load-bearing in one of those cases.
The simdnoise crate with an LLVM assertion: This is not a regression, it's confirmed to also fail on 1.28.0 (alt builds are not available past that).
Wow, this one's amazing.
This one still reproduces on master.
Unfortunately, I wasn't able to get this to assert with and a separate invocation.
Can an absolute beginner take this one?Let me know if someone is working on this already
This is an assertion failure in the very depths of LLVM's machine code backend, you can try to find a minimal test case if you want, but I wouldn't recommend finding or fixing the actual bug to a beginner (but feel free to try if you feel very ambitious!). You can also try your hand at one of the issues, which are specifically meant for beginners.
Did you use an assertion-enabled build? I tried again just now and am still seeing the assertion:
my bad, new nightly builds don't have llvm assertions enabled.