jiebi/CodeConvo huggingface dataset:
Looking at without prior knowledge of Windows system call semantics, I see an infinite loop if the syscall were to fill up the buffer exactly: when k == n on line 195, the loop will be rerun with no changes, which should result in the exact same outcome if the syscall is idempotent. Even if Windows guarantees in some way that this cannot happen, would it not be clearer to handle this case in an obvious fashion?
Here's one of the docs on how usually works in Win32: Note the difference in lengths between success and failure. So there's two potential cases where : Success: If the buffer size (with NULL) were to be equal to the successfully copied size (without NULL) then the buffer would be too small to hold the full string (NULL included). So this can't happen. Failure: If the buffer size (with NULL) were to be equal to the buffer size needed (with NULL) then the string would have been successfully copied into the buffer. So this can't happen. So Windows does indeed guarantee this can't happen.
OTOH on some versions returns the size written including the NUL terminator, so for that function the infinite loop could happen, right? The doubling logic that checks for the insufficient buffer error code must be there for some other function that I have not yet found, it would be great to have a comment as to where this behavior is needed.
As far as I know Rust only ever uses the Unicode version of functions (they end in ) and never the "ANSI" ones (they end in ). The functions are more consistent across Windows versions. I'm not at all against adding a comment (and returning an error?) in this case but it's not something that should ever happen with the kinds of APIs Rust uses.
Come to think of it pretty much implies using the functions. It uses a buffer, where as the functions use a buffer. Using this function with the functions would be very broken.
Still, it would be more robust to change the into , so treat this presumed impossible case as success (absent other evidence) rather than looping.
My issue with assuming success is that we can't know what a hypothetical Win32 function is doing in this case. For example, it may have truncated the output or it may even be returning an error code, not a size. We can only guess. Best case is we guess right and it works.
Worse case is we guess wrong and it causes a bug that only becomes apparent later on, making the source of the bug hard to track down. Having given more thought to this, I'm leaning towards using . That would clearly document that the case is thought impossible, while also causing a panic if the function is misused. It might also be good to clearly document the expected return for the function being passed in. E.g.: On success returns the size of the copied string excluding the terminating null. On error returns zero unless the last-error code is set to . If the last-error code is returns the buffer size required, including space for a terminating null.
Yes, that sounds like a good improvement! Since this Win32 behavior is not generically documented, it might also be good to note the exact syscalls that this function has been tested with. I should probably mention that I don’t have a Windows system to develop or test this on, I was merely perusing the code out of curiosity — otherwise I’d volunteer a PR.
upstream/master:
Does that build include the fix in
Yes, include. 6:45 "Huon Wilson" notifications
Thanks for confirming. cc
Reproduced on revision . Note that I'm using win 8.1 with non-english locale which probably causes issues. Quick investigation: then convert the code into string. It seems that failed with .
So the issue is broken into two parts: 1. why rustdoc failed and called ? 2. why failed?
When compiling a personal project, I got an error that the compiler panicked and entered unreachable code. I've dumped the output: And I committed my code which caused the bug here: It might be because I had only written half of an anonymous function at at line 92. This is not that urgent as I only saw it with half-written code, but since the compiler suggested I file a bug I did. :
Good call! Reducing it to is enough to trigger the ICE. <details<summarybacktrace </summary
modify labels: I-ICE T-compiler C-bug A-frontend
I've traced the problem down to this call:
triage: P-high, removing nomination label.
has made it impossible to import some structures in when implementing dataflow analyses in external tools. When implementing for a custom dataflow problem, we can no longer import the or direction. is the source code of such an implementation. is needed to set the type of the trait. Previously, it under the export, but for now it is . The default implementation of the , so I can simply use the default value as a workaround. However, if I need to write a backward analysis, I must rewrite some parts of the framework in our source code because they cannot be imported. There are other tools in the ecosystem that use that API, e.g.: These changes will make problems if they decide to update to the recent toolchain. Could you please take a look at this matter? Are these changes intentional? Could we make some of the exports public again? cc
Feel free to send in a PR to make it public again. Please add a comment on the items saying they're used by external tools.
I will double-check which of the removed imports might be beneficial for external tools and will send a PR if there are no objections.
This is a tracking issue for reverting the change introduced in which disabled the toolstate check for the edition-guide. It is currently blocked on which is causing a test failure in the edition-guide. I will reinstate the check as soon as that issue is fixed. has requested the labels t-release and I-nominated.
Tags are so that we don't forget this, we should keep it nominated until it's fixed.
The check was reinstated in PR
I think you have the wrong issue? There were two things (rls and edition guide). The PR you noted just reverted the RLS change. The edition-guide was separate (and done in a different way). It's still blocked on .
, that's what happen when I read just half of the title :sweat_smile:
triage: P-high. Assigning to self. Will likewise triage . Removing nominated tag.
actually I'll leave nominated tag, since this is for a team other than T-compiler so I don't want to mess with their tags.
(allowing specifying code models was to rustc in ) I want to build a large code model binary. But (correct me if I'm wrong) I believe this requires all code to be generated with a large code model (otherwise we could end up with rip relative addressing in the stdlib, which defeats the point). So I tried the obvious (controlling it with ) and got the following build log: Brief explanation of the three parts: command is run tail end of the stage1 stdlib and rustc itself being built by stage0 tail end of the stage1 stdlib and rustc itself being copied out of the stage0 build directory and into the stage1 directory, then the new stage1 rustc attempting to build the first part of the stage2 stdlib (libcore) segfaulting In fact, this stage1 rustc segfaults when not doing much: Reducing the command line used to build rustc: GDB gives the backtrace as I've dumped a bunch of info in the hope that someone might be able to lend a hand, but I can find little discussion of this feature (code models) so they may not be well-tested? I plan to investigate myself, but wanted a) to see if anyone has any pointers and b) make this a searchable issue. As a datapoint, note that redox uses a .json target specification and with , which obviously works fine. Altering the configure+make command I used to use the kernel model rather than large also worked fine. So it looks like the issue is with memory model large.
Compiling statically (with glibc, as described at ) makes it not segfault, which is interesting. Doing --enable-debug in configure also makes it not segfault. I starting to suspect the issue is in llvm (I don't think anything in the rust compiler itself generates asm?) and rust tickles the bug somehow.
Recompiling just the libstd crate without optimisations makes it work. It appears that start , which attempts to calls . calls on linux. By inspection of the parameters passed to in the linux implementation of with gdb, the parameter is an invalid pointer (checked by inspecting by ). In theory should be in steps 2 and 3, though the functions look like they've all been inlined.
Managed to tear down std to get this test case: (it seems that since I originally reported this issue, the nightlies now have llvm assertions enabled)
Abort seems to be coming from TwoAddressInstructionPass. Backtrace (from gdb) at the point of abort is: <details<summaryClick to expand backtrace</summary<p</p</details
The rust code two comments up () when compiled with will produce . Inspecting with llvm-dis: If you now try and compile this with you will hit the assertion (assuming your llvm has assertions enabled): It works fine on the latest LLVM head. Turns out the fix was merged december 7th - is the bug, is the fix.
Looking at the llvm 4 release branch on the llvm-mirror github, this will be fixed when rust upgrades -
I backported the referenced patch, built a debug rust with it (i.e. debug-rust-large-fixed) and then built a release mode rust also with the backported patch and debug-rust-large-fixed (which took forever) and successfully ended up with a release-rust-large-fixed which can build itself.
Presumably fixed by LLVM backport -- doesn't reproduce today. I'm marking as E-needstest since it seems like something we should track in tests.
fwiw this is tricky to do a test for unless we want to do yet another rustc build in CI. I'm going to be rebasing our Rust fork 'shortly' and was planning to just close this issue once that's done and I've verified everything is working.
Oh... do we need to rebuild rustc for it? I was under the impression that just was enough to test. That's all I did...
Urgh yes. Sorry, this issue has a lot of history for me and I'd forgotten parts of it. Running the testcase above is indeed a valid test of the issue :)
Triage: apparently a test, but it was removed before it was merged.
<!-- 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: code compiles in a reasonable amount of times or the slice gets elided entirely. Instead, this happened: code takes multiple minutes to compile/gets killed by the playground. <!-- 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. --: Also tested on playground stable and nightly.
The code compiled in about 6 seconds in Rust 1.29 and 1.30 : . Before that it had capacity error. After that it exceeded 15 seconds limit of godbolt. This is a but I cannot tag it.
It looks like this also works correctly on 1.31 stable as well:
Decided on as in the prioritization working group procedure.
Cc
Fixed 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. --code from <!-- 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
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `
<!-- 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. --I tried this: (at ) windows-gnu nightly: wasm target: the package for : Result: The invokes . depends on that is not present in the distribution. If I add it manually, the issue goes away. The flavor ships with that does not have this dependency. and (and likely everything between)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low +T-compiler +O-windows Edit: my assessment was wrong, this requires more prompt attention label -P-low +P-high
I have the same issue with "stable" rust 1.52.1 ( 2021-05-09) on Windows 10 with a wasm32-unknown-unknown target. Can you elaborate on how to quick-fix this by adding manually? Where can I get, and where do I put I only have from Mingw64, Mingw32, and many other SW packages. Is it the same? Btw. what hit me instantly is the move from LLVM 11 to 12. Might that be the issue?
Yes, at least enough so it works for me. Just rename any zlib binary, the library interface has been stable for a very long time, so it should just work. Or, if you are ok with using binaries received from strangers, take this: . When you have , you need to make it visible. Either place it in any location visible in environment variable, or place it next to the . For me it is located in . See if you want in-depth explanation where the Windows looks for the DLLs.
It works, thanks a lot. It was a bit confusing that I don't have rust-lld in the wasm target folder. Now I can work on my fullstack project again without worrying about OS specific issues :-)
this is my attempt to bootstrap rust-1.75.0 beta, which fails with this beauty: this is my command: I can workaround this by reverting can you please have a look at this error and the backtrace? I don't get why this error comes up. Thanks
this is my
The fixme here seems to be the issue: As workaround you can try to run before the build. cc
I'm compiling offline, from the beta src tarball.
I'm aware. It seems that there is a bug when using vendored sources in combination with remap-debuginfo. Creating the directory should help even if it is kept empty.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Well, the cargo eclass is already exporting CARGOHOME env var, and a CARGOREGISTRY_DIR as well, and I'm doubtfull about the package manager allowing x.py to escape it's sandbox. Neverthelss, I'll try your suggestion when I'm back home on the machine.
If you have set the directory you need to create is .
for your information only
From . This means we do not blanket turn on LLVM assertions on all of our bots, which we would ideally like to do. I'm going to try turning them off for just the cross bot though.
cc cc
Seems related to somewhat. We do not use the maxnum intrinsic (totally should!) but from the existence of bug for maxnum seems to suggest that a similar issue for some non-maxnum intrinsic is likely to exist (and libcore is kinda intrinsic-heavy).
Case sensitivity is a property of the filesystem, not operating system and these functions are filesystem agnostic. As thus, this issue is not actionable. Closing. If you feel differently please complain and I’ll reopen.
It's fine if the functions want to be case-sensitive, but their docs need to be changed to point this out explicitly and noticeably. Every Windows user is going to assume that the functions are case-insensitive just like they are in other languages on the platform. (I imagine OSX users will have the same expectation?) It's made slightly worse because is handled in a special way that makes evaluate to despite the mismatched case. So someone using that as a quick test of their assumption would end up with the wrong idea. Would you mind reopening for this reason?
I think it would also be good to have a crate like provide a that does hit the filesystem. Such an API would also be able to detect when the same folder is specified but using alternate prefixes or mount points or through symbolic links.
The driver letter is a symlink in the Object Manager and lookup is always case-insensitive. Folders are located on the filesystem and may or may not be case sensitive. I do think platform specific behaviour should be documented if it can be a source of confusion.
Trying to package rust 1.2 into Debian & Ubuntu, I get the following test failures: I am using Debian LLVM 3.6.1 packages (version 3.6.1-1)
is in the package. I wonder whether we want a check in that makes a requirement or one that disables the respective tests if it is not available.
That was indeed the issue. I installed it and I have issue now.
Addressed in
These test should be optional until LLVM has a way to install FileCheck
I tried to get a minimal example, now i just ended up with completely senseless code, that still gives the error. playpen says: if you remove the for loop, only the last two cat_expr notes are left. adding more code just ends up with more of the notes.
this is pretty much my fault. :) In all the cases that I have seen where it arises, it is due to a type error (or a type inference failure at at least) somewhere in the code. Of course the notes are incredibly annoying. I will try to fix.
And of course the concrete example given here is one where there is no type error. At least, not one exposed by compiling this code. (I have not yet managed to show being instantiated concretely without causing some other type error to arise.)
(but there may be a mix of bugs causing the original input here to pass. In particular, the code in the description is doing , but that associated type does not exist. One needs . See also: )
cc
Compiling project with causes the following compilation error: See this .
cc target maintainer
I guess has the same issue? This got broken by ("unix time module now return result") which dropped I guess the way forward is to make use instead. I'm wondering if there is a way to make sure that this kind of breakage doesn't happen before a rustc release?
Our platform support policy is to avoid blocking PRs on whether tier 3 platforms build, because tier 3 platforms are not required to build.
Sure, I'm not saying to block PRs, but I'm wondering about somehow getting notified quickly enough to be able to react before a rustc release.
(as in: getting the break notice from a getrandom CI build a dozen days after the merge does not look that robust)
Hm. Does the Rust compiler for hurd get built from a stable or beta branch of rustc? My understanding was that tier 3 targets generally used the nightly compiler in any case.
In Debian we will use the stable releases to compile all rust-needing Debian packages, as the Debian policy requires.
The breaking commit is not in the current 1.77 release but is in the 1.78 beta. It will not be in a stable release for another 5 weeks-ish. Would you like your PR that fixes it to be beta-nominated, so that it gets backported and is in the stable release of 1.78?
Yes, please.
I recommend you set up a daily/weekly job on your side building master to check for regressions. ( may fix this)
I wanted to try out the missingdoccodeexamples rustdoc lint, but it seems to be bugged. I tried following the example given in . Steps to reproduce: Create a new crate: Then edit the file: I would now expect to get a linting error when building the crate, since the add function is public, but does not have a code example. However, as well as and completes without any errors.
The lint only works on nightly, the docs should probably be updated.
These docs live in To fix this, add 'and is nightly-only' to the first sentence.
I created PR to update the documentation. Thanks for clarifying. :-)
Was working on bug and tried to compile the program below. The inline assembly may be bogus: I make no guarantees of its correctness. crashed with this output: : (but also happened on a nightly from late May)
The inline assembly is in fact bogus. Here's a minimal example that crashes the compiler. The problem is likely using the string operand (by mistake, because I'm dumb).
<details<summarybacktrace</summary</details
modify labels: I-ICE T-compiler A-inline-assembly C-bug
Thank you!
Added in these options are still unstable, this issue will track their progress to becoming stable!
Also note that is adding Cargo support, currently through and , but as we may want more human readable names.
I don't even think there is a single word that describes what does. As far as I know it was first introduced in clang and selected for its closeness to and connotations of compression, but this doesn't help at all when you need an immediately understandable token in
/ for and for ?
is right, "s" and "z" are not clear at all. I had no idea what "z" even did until I looked it up. it is the same as "s" but without loop vectorisation. According to it is intended to reduce size even further. I like the "size-1"/"size-2" idea.
We are potentially interested in this for Gecko's integration of Rust code, see [1]. We'd need to do more measurements to determine if the performance impact is acceptable though. [1]
thanks for the info! We haven't seen a lot of movement here in awhile and we've got support in Cargo/build scripts now, so I'd like to propose we stabilize this: 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] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once these reviewers reach consensus, 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.
IS this properly documented? That can come after we've approved for stability, right?
good point! I think we should definitely make sure it's documented at least in or the various man pages.
yes, that should come before the final PR itself lands though.
It seems like there was an open concern that these tokens (especially for Cargo) aren't very clear. Do we want to take a short at single-word tokens before stabilizing?
I'm not personally motivated to do so as this is such a niche feature it seems like it's not worth the effort, but others may feel differently.
I feel differently!
If I change the patch to , and would that be acceptable? Or is it too late since Cargo has already merged and ? If so then we should probably stick with that but they should be properly documented since clearly very few people know what they mean.
I think we're definitely still able to change, we just might have to have a small period of time where we support everything to deprecate s/z
is there any particular reason that, for Cargo, we need more than just ? In practice, the main historical distinction between and was that was OSX-specific, and gave you "definitely, for realz optimize for size." As far as I can tell, Cargo really only needs a way for people to say "I want you to optimize for size, please" and having multiple different versions of "optimize for size" at the Cargo level seems likely to introduce more confusion than help. I propose that we add to Cargo, and not leak and . I think I feel the same way about but don't have as strong of an opinion there.
Sounds plausible to me! In that case sounds like there's work to do, so I'll cancel the FCP fcp cancel
proposal cancelled.
That's not what does, as far as I can tell. According to Clang's manual: Also see . By the way, there is also ! , which is: Sounds like it could be useful. I suggest for that.
I came here because I wasn't sure what -Oz did - now I know. I would like to point out that "size1" and "size2" is not much better, imho. Ok, so there's a size difference. But which one is supposed to be smaller? The bigger number, because it tries more agressively to make it smaller, or the smaller number, for intuitive reasons? I can see the parallel with O1, O2, O3 -increasing optimization for speed, and S1, S2, S3 -increasing optimization for size, but perhaps this should be made more explicit then? We can always keep "s", "o", and so on as shorthand aliases
Hello This seems to have gone to sleep. I mean, the name for it is important, but no discussion seems to be happening for like 9 months ‒ is it likely to move forward?