jiebi/CodeConvo huggingface dataset:
First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .
broke the rust-analyzer config we suggest in the dev-guide: https://rustc-dev- since now rustfmt is in instead of . Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Hi! Just to clarify, the idea is to change to code to match the docs?
I think the idea is changing the docs to match the new behavior.
For reference:
I'd prefer to change the code so that we don't force all contributors to update their config.
I don't think we can put the binary back, or at least, that feels iffy - we'd be trying to overlap two different sysroots. rustfmt used to be statically linked to libstd and librustc_driver, but that's no longer the case.
I suppose we could try to create a symlink from the old path to the new one? That might work, not sure.
Maybe add a proxy? On Linux it might just be
A symlink seems like a good solution to me.
Does the symlink still finds the correct so?
try it and see
I'll experiment adding a symlink.
On Windows, creating a symlink does not find the needed DLLs. Trying to execute the symlink pops two msgbox saying that it doesn't find the and DLLs. You would need to symlink also the DLLs. On Linux, it does find the correct SOs.
Symlinking also works on macOS.
Ok, this is pretty messy. How about doing both: Add the symlink, which will work with both the old and new config on Mac and Linux Update the recommended config in the dev-guide, which will help contributors fix the error message on Windows and from there we can work long-term to using the same toolchain for rustfmt and other tools, without having a time pressure.
cc ,
May I get some guidance and the creation of the symlink? Do I use rust to create the symlink in after the rustfmt_path line or do I use a bash command? If I do use a bash command, is there a file I should be adding it to? Thank you!
use
And just to confirm, I use that symlink function here?
yes
I think it would be possible to move rustfmt back to the same sysroot as the bootstrap compiler by only taking , and from the nightly rustc component and not copying any other files like the rustc binary. and both contain a hash in their name unique for each rustc version. should contain the rustc version, so that shouldn't conflict either.
Doing the same with the DLLs on Windows could also work.
related (different error with rustfmt, but caused by the same change):
Hi any progress on the symlink? happy to help out if you're running into trouble :)
Hey ! Thanks for reaching out! I'll be starting tomorrow and will reach out to you if/when I need help! Apologies for the delay!
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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 compiler team prioritization.
triage: P-medium. Removing nomination label.
While working on I've discovered that on nightly the std::Command::new() for a windows 10 batch script "" results in underlying node-js process to not find required resource paths. I tried this code: I expected to see this happen: This works on all channels for my linux and windows 7 boxes (did not test other than msvc here) as well as stable and beta for windows 10 box (and appveyor) Instead, this happened only on windows 10 (and appveyor) msvc nightly: Please note that the panic is explicitly triggered in to make appveyor report the error. The sets paths for node-js via environmental variables and these seem not to be forwarded properly. Sorry for mostly useless description as I have no experience with npm/node and no access to the actual win10 box on which the problem was reproduced (I was only able to locate this problem via appveor logs). But the problem exists at least since (sorry no verbose output here. I have no access to that win10 box anymore) Link to appveyor showing the problem:
So you're saying the combination of Rust nightly and either appveyor or Windows 10 is causing the npm stuff to fail? Also, the actual error that is occurring here:
What I was able to gather sofar is that env variables in the cmd script might not be forwarded correctly to the nodejs subprocess.
what makes you think this is a rustc bug? It's looking like the process was spawned correctly and output was captured, which makes me think that this may be a local configuration issue?
I am not positive that it is a rustc bug. But identical setup works on windows7 (stable/beta/nightly) as well as the exact same setup works for windows 10 stable/beta and fails on nightly suggests that this might be a regression in stdlib. I am assuming that while process start and output capture works, there might be problem with how the env variables are passed to the child process. I'm no expert on windows nor nodejs (I just happened to help with triage on ) I am assuming that very specific contents of trigger this behavior. I might try to get a hold of win10 box again and try to get the reproduction path down to a manageable minimum.
After some investigating it turns out this is an interesting Windows feature/quirk/bug in how is handled.
We're seeing this now in Rust because of (so my bad). is supposed to return the drive and path to the running batch file but that can fail if it was called with a quoted name. This isn't a new issue: Note that this can still be triggered on stable if the name of the batch file contains a space such as so reverting won't really help. What I suggest doing in this case is using instead which seems to work around the issue. It's also what you should be doing according to the  docs.
Marking as a regression from stable to beta, which I think is now true? Uncertain. Either way, I suspect we should consider this a compatibility note and close, since based on comment directly above people using this functionality should be doing so differently according to the Windows documentation.
This is an annoying regression though. Because instead of having to cfg only the name of the binary you now have to cfg all the places where you create / run the command because you need different args etc. We used the method below in our , but in the actual code the part is repeated a couple of times in different places. So this regression would result in more cfg boilerplate.
I would opt for a fix instead of closing with compatibility note based on the fact that problem is focused on windows 10 and nightly (not sure if it has already crawled into beta) with the original (stable) behaviour being desirable and this regression possibly affecting large number of crates but being hard to catch with cargo bomb (i suppose that not many crates run windows cmd scripts in their regression tests) You are essentially suggesting that crates / binaries implement a workaround. IMHO this is what stdlib is for (providing a portable abstraction) and client code should not be interested (or even aware) of the fine details of underlying implementation.
something like the following should work and as I mentioned should probably be done anyway. Is it? I haven't been able to reproduce any differences between Window 10 64 bit and Windows 7 32 bit in a VM. The Stack Overflow answer I linked talks about this in Windows XP so if there really is a difference between 7 and 10 then there might be a different bug. I believe the best place for the workaround is in the batch files themselves. Using a subroutine (like shown ) for seems to be the only reliable thing to do.
doesn't provide a portable way to run batch files. If you use then you have to specify the file extension anyway so using isn't really any less portable. Client code should not rely on the fine details of the underlying implementation either, in this case whether the executable name is quoted. is a bit of a mess on Windows. In this case it's definitely the fault of Windows. is Rust's fault though. It wouldn't be a disaster to revert and return to the previous behaviour which just has different bugs.
My comments (sofar and below) may came out negative so please excuse me. I understand the technical details and greately appreciate the work you guys are doing here! I can live with any workaround in my code really and this is more of a concerned citizen speaking as I find this problem a serious regression (as noted the problem did not occur in stable nor beta and its win 10 speciffic) the fact that problem is focused on windows 10 yep. I was able to reproduce the problem only on borrowed win 10 laptop and nightly (it does not reproduce on win 7 nor on any platform when using stable and beta - the statement about beta might no longer be true if the problem code migrated there) and in appveyor VM (as before the problem was on nightly only) Then there should be a section in docs mentioning that. In sane OS es there is no distinction and windows strives to make it transparent for the most part. Which is a bug in itself requiring a workaround in user code. This exactly proves my point about providing portable abstractions instead of leaking backend specific requirements to the user. to say the least :/ The uses but I'll not be able to verify if the workaround works untill I'm back from holidays in 1.5 weeks. Is there a chance to leave this issue open untill I have chance to verify the workaround on my side? Thanks for your time!
Thanks for the suggestion, it is cleaner than what I was going to write :) Command is a bit of a mess on Windows. In this case it's definitely the fault of Windows. is Rust's fault though. Indeed, it seems like it. If there is no way to abstract the Windows part away to provide a more unified abstraction, so be it. I can live with the workaround.
It would be a shame though, because I suppose a lot of people use in their build script and would be happy if it worked seamlessly on all the platforms. Personally, I don't have a Windows machine to test my code on, I just assume std code is cross-platform if I don't use OS specific modules. Maybe it is a wrong assumption to make, but so far it has worked out pretty well and that is just amazing! I guess I'm just asking to not dismiss this issue too quickly because it is not "our fault" and see if we can end up with something better. Even if it wasn't working flawlessly in a cross-platform way before, I would consider diverging further as a serious regression that should at least be well thought out.
The fact that you even can run bat files with honestly feels like a backwards compatibility hack that Microsoft wishes they could undo. A bat file is not a binary, and when you do run it the process which is actually running is . Unfortunately the fact that is able to run bat files at all leads people into the false belief that it is any good at that. In fact, imposing the requirement that be able to run bat files precludes us from adding the ability to run binaries from paths longer than ! In order to support long paths, we'd have to specify the application name in the parameter, which does not support executing bat files directly! So please, just use instead of executing bat files directly so that Rust will have the ability to make better in the future.
I would like to excuse for the terse form (I'm on mobile only) so please take this with grain of salt. It might be but I have not encountered a modern language stdlib that would not allow running bat files within the PATH. But if this is the policy then either forbid it explicitly in API or at least document such limitation in the docs. neither are any other executable scripts on NIXes. IMHO this is besides the point Please note that we are discussing two completely different entities. You are mentioning the internal Windows implementation and its limitations which I perfectly understand. While I'm talking about the user facing rust API that IMHO should hide as many platform specific warts as possible and document its limitations if former is not possible.
Also I have a big problem with accepting a "wont fix" on a regression with an explanation such as "this was always a mistake and we should have never allowed it". I understand API stability not only as a "compilability" but also behavioral contract. Please note that (possibly most) stdlib users might consider not being able to run bat files directly a serious drawback (not found in other mainstream languages).
Hmm this still came out stronger than intended . Please note that as a pragmatic programmer I'll test and implement the suggested workaround (thanks for the help with that!) previous comments were a well intended suggestions from someone concerned about rust and its success on the crowded programming language market. Please keep at the good work!:heart:
If you want something that is capable of running any executable script, what you really want is a wrapper around and not . In order to spawn a child process, Rust has to use either or . Rust decided to use which means it is fundamentally limited in the sort of behavior it can support by what does. In order to paper over differences in behavior between platforms Rust has to do a lot of its own work, such as searching in itself if you modify the of the to emulate posix semantics and that's already given rise to a bunch of bugs (). When Rust goes too far in providing cross platform behavior it ends up causing bugs like Some things simply do not work when you try to make the behavior the same across platforms Rust cannot completely unify the behavior across platforms. At some point Rust has to draw a line for where the platforms have different behavior and document it accordingly. fixes an issue which could result in a security hole. You could attempt to run but if it doesn't exist it might end up running a completely different binary named . It would be great if we could provide complete stability in behavior, but when fixing bugs there will inevitably be some corner case that is broken. It's unfortunate that quoting the binary name causes to no longer work but fortunately there is a clear way to change your code such that it reliably works across all Rust versions. I really wish we could let support binary paths longer than but a lot of people already rely on being able to directly execute bat scripts, far more than those that relied on , so I don't think we'll ever be able to fix this bug.
Because of std's stability guarantees it looks like if we ever want a good we'll have to rely on third party crates.
Thanks for the background information. I feel bad to have wasted so much of your time on a discussion that was less than productive so feel free to disregard my ramblings. I think that this might be the best course of action.
do you have thoughts here? Or do you agree with the previous summaries?
I was quite surprised to learn that can execute batch scripts at all. .aspx) explicitly says "To run a batch file, you must start the command interpreter; set lpApplicationName to and set lpCommandLine to the following arguments: /c plus the name of the batch file." I agree with that trying to abstract away all platform differences is fraught with peril.
Ok thanks for the info In light of that the libs team's conclusion during the meeting of "we're not going to revert" I believe still stands, so I'm going to close this. If there's difficulty in updating applications though please let us know! We can try to help work around it if necessary.
In light of that the libs team's conclusion during the meeting of "we're not going to revert" I believe still stands, so I'm going to close this. I am fine with the decision, but could I ask for more explicit documentation about this behavior? The example on the shows the right thing to do, but it is never explicitly explained. Having a note about this in the docs would probably help avoid some confusion for people that are less familiar with Windows, like myself. :smile:
Agreed. Actually I would also expect that such change in behaviour would also be mentioned in the rust release notes. Even if the original behaviour was unintended side effect, this is an important change in behavioral contract for stdlib.
in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered?
We already translate from C-style formatting strings to Rust formatting strings when passed to the family of macros. We should also detect invalid calls from other languages that were meant to be macro calls: currently emits the dry while it could be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Mentoring on this issue label +E-mentor
Reduced example
e
The first compilation error -- the example with looks fine to me. Types used for static variables must outlive the lifetime. The compiler can prove that outlives only if . Hence lifetimes are inferred in lieu of the anonymous lifetimes. Since your variable does not live for the whole lifetime, it cannot be used as you are trying to. Maybe the actual bug is that should desugar to , as it would be for ? It may be weird to special-case only the traits though -- i.e. if you define your own trait , then just means for some lifetime to be inferred by the compiler, it does not mean . Your reduced example is actually different since it actually does not involve static data. It seems to be the same bug as in , and hence is a bug with the feature. Going from to (note the tuple of size ) makes the ICE go away.
Fixed by
With and the following file: the command fails while installing docs because it can't find the target's directory. This makes sense because the directory is created in one of two places: and both of these are only invoked for the host (in the enclosing impls of each of those call sites, is set to true). So the problem is that the step, which relies on the existence of the directory (see ), is run for the target ( ), but the steps that would create that directory have only been run for the host. I was able to fix this by adding inside the ( ), so that rustc docs aren't generated for the target. I'm not sure if that's the right solution, and in general I'm unsure about the logic for which pieces of documentation are generated for the host and which ones for the target under cross-compilation. The end of the output, showing that fails due to reading a nonexistent directory, is:
n.b. I'm not sure I actually was using correctly -- my goal is to cross-compile snapshots that I can use for bootstrapping Rust on a riscv64 system, and based on the output, I think I probably should have used: instead. But this still shouldn't happen.
I think this will be fixed by
In general RustcDocs is pretty broken, see
merged but this is still unfortunately still an issue :( reproduced with did you ever find a quick workaround?
The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: or similar. The note and/or help are both subject to changes, this is just a basic idea. We could also conceivably rewrite the error message to expand on what the note says, like so: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It's hard to get 'c' in line 3 during the context where the compiler errors out the second mutable borrow message, because the mutable borrow happens between
I don't think it's critical to mention in the diagnostic. We shouldn't let the difficulty of doing that stop us from trying to improve the message. label +D-newcomer-roadblock
I'd love to try to fix this, but sadly I'm not familiar with the internals of rustc. If someone could point me towards the section where this error is, I could give it a try.
Hi ! Whenever I try to dive into fixing a problem with rustc, I usually start with a search through the codebase. In this case, I'd search for strings that come from the error message: , , or : <img width="528" alt="image" src="https://user-"And that leads me to here: So then I'd use rust-analyzer to try to find all the usages of that method.