<!-- 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


Tagging as E-easy and E-mentor. The fix here involves changing the code to call to prevent the temp dir from destroying itself. This should be wrapped in an if like this one:
Hi, I want to try working on this.
Go ahead! Let me know if you need any assistance - feel free to either reach out here or over IRC (simulacrum is my handle there).


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


The build system that we just turned on is not actually in the source code. cc
This is on beta and nightly too.
Reeopening until the backport is fixed because I'm putting this on the release milestone.
Backported in as


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!


The code around opt-levels indicates only nightly can use or . Non-nightly s should not even report those values as possible options.


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?


As for me, I'd rather have the feature stabilized (I'm often aiming at devices with chronic lack of storage space), no matter the actual values used. Or is it blocked on anything else beside choosing the right name?
Side note: the crash in only reproduces with -Os (probably an LLVM bug)
Since the lastest LLVM upgrade rustc / LLVM does more agressive ~inlining~ loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. . As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable. What can we do to move this forward. Can we at least stabilize "s" on rustc? Cargo already allows in the but requires a nightly toolchain. is this (opt-level) being discussed as part of the Cargo profile revamp?
I think those optimizations have baked long enough that it should be fine to stabilize now personally!


The following code : run under miri reports UB:
cc
The underlying issue is in : this has the same error.
This is actually tricky, I think -- an unexpected consequence of the Stacked Borrows rules. When is being passed to , it gets reborrowed and then "protected", meaning the mutable reference passed to must outlive that function call. But then it goes ahead and reads the old reference from directly via the raw pointer, which reborrows that reference, therefore invalidating the earlier other reborrow. There is a sense in which the reborrow of passed to is truly invalidated here -- and in fact it is not possible to access that value later: I am surprised by this error, since usually mutable references are reborrowed, not moved. But it seems here it somehow knows not to reborrow?
cc -- could be related? Fully-qualifying the call with yields a different error (where reborrowed rather than moved), so it seems at least partially related:
Ah, yes that's it. Not that the exact error makes such a big difference, but now at least it is more clear that the reborrow makes later uses of fail.
Type inference will prevent reborrowing from happening.
Could we say that a mutable reference that comes from a type parameter shouldn't be protected?
That seems a bit strange, to have a particular instance of a generic function behave differently than if that same instance had been written monomorphically.
Well, generic function is different from an monomorphic function. In a monomorphic function you can dereference the reference, but (if there're no bounds) then in generic function you just have and would need to treat it "just as data" and the fact it's monomorphized to be a reference shouldn't be special. I.e. I would expect a to behave more closely to or than a dedicated, say type. It is strange to me that two monomorphized versions of the same function should behave differently.
Sure, a monomorphic function can be changed to do more things. But when a generic and monomorphic function are the same in the source code, they also should behave the same. They use completely different types, so them behaving the same does not even make sense? Like, e.g., will literally return different values. In general, two monomorphized versions of the same function have no choice but to behave differently.


To give another example, if you a to , then again of course this is UB for some (e.g., ) but totally fine for others (e.g., ).


STR: run with on a program with a name resolution error. Result: cc (bug manifests in the RLS)
I can take this. I already dug into some time ago, I encountered the same bug when I was trying to write a refactoring tool. To fix the issue, I have to remove all the around there, right ?
great, thanks for digging in. There's likely to be some s that don't need to be there, but it won't be quite as simple as just ripping them out. There will be some error condition that needs to be dealt with.


Note: The regression is valid/"allowed" (there's a hole in the typesystem being patched), I'm just filing this issue now so we can make sure that this regression is tracked in case it got "fixed" by accident. Feel free to close if it's a known quantity; I'm just worried that this got "accidentally" fixed in some other change. My crate is being fixed to not face this problem, but in general there's a chance other crates are falling afoul of this as well; we should perhaps assess the impact and start off with it being a future incompatibility warning if necessary. I tried this code: () I expected to see this happen: It compiles, like it does on stable, or at least throws a future incompatibility warning. Instead, this happened: It errors: It most recently worked on: Rust 1.56.0
This regressed in , which was a rollup. Further testing shows this resulted from . It's marked as being a partial revert, so I'm not entirely sure what the chronology is here. CC Note that we think this "regression" probably isn't actually a problem, per the note at the top.
What the....
Okay so reverting fully also errors. Stable 1.55.0 fails. Checking (a couple commits before ) now, but I'm assuming it's going to error. So, this was actually a bug in 1.56.0 - prior to that, this didn't compile, rightfully. My guess is because of treating unnormalized function args & output as WF, we saw , replaced it with , assumed that was WF, so we didn't actually check that . I'm going to go ahead and make a PR to add a test that closes this issue. This was a bug in 1.56.0, not a regression since.
Good to know, thanks! (And good that this was just a one-version regression; less chance of there being in-the-wild breakage)
I should figure out an excuse to make yoke a dependency of rustc, it seems really good at finding typesystem corner cases and maybe we should just have it be a test
Isn't it failing on the wrong line?


I would have expected it to fail on the because is the thing that needs to match
Haha yeah, it's a thorn in my side So, it's interesting. The check is , which is true. What I might expect here is it to fail because you haven't written (which is required for to be well-formed. But I think this is implied bounds, since this is fine:
In my experience WFness of has always been a bit variable where sometimes you can assume it and sometimes it requires you to spell it out, so maybe this is another instance of that.
Thanks!


We currently emit vec growth glue, but it is called using the push/pop mechanism (e.g. of transcallglue). In reality, the only call site for this glue is generated when translating vec append statements, so it really is user-level glue and need not adhere to the "worst-case glue-call args" max argument count. The fact that we don't do this costs us one extra word of worst-case glue-call args at the moment (7 words instead of the 6 we'd need otherwise). This is a relatively minor issue, but now noted.
WONTFIX (not required for bootstrapping)


Currently, pointers stored on the stack aren't word-aligned. This is a critical issue because it causes stack growth to fail most of the time.
Commit disables task growth for now until this is fixed.
WONTFIX (moot point given disabled stack growth)


u32(1234) should be 1234u32, and handled in the lexer The former is chatty and confuses the issue with runtime calls / casts (the latter of which should be shifted to 'as' casts anyway).
Switch machine-type lexemes to use suffixes. Remove support for foo(bar) as a cast notation. Closed by .


This error occurred when running . Should I remove these unused attributes?
What's your ? These should only warn, not error.
This is a part of my which is not commented out.
If you run and check again, these warnings should go away. It would be nice if this wasn't necessary, though.
Thank you for your advice! clean and then build completed successfully!
This happens to me every time I try to do an incremental build after making a change. Is there any other way to resolve this than ?
Let's keep this issue open, because we'd rather not have to clean even single time.
I'm running into the same problem with incremental builds, which makes incremental kind of useless...
I think I am also running into this. I'm going to tag this T-compiler to try to increase visibility
I am also running into this
This is super painful, can this gets prioritized, or could we disable incremental builds until its fixed?
FYI, the following command seems like a pretty reliable way to reproduce this problem:
(assigning to self to investigate)
Strange; part of the problem I have had in investigating this is that it seemed like my manual attempts to run the "same" commands that were being issued by bootstrap would all complete successfully. I think part of the issue there is that the mode for is sometimes hiding information about the commands it runs. To get something that actually reproduced the problem, I had to drop into the "more verbose" mode by passing twice to , like so: and an interesting part about that output is that I saw these two lines right next to each other in the output: The first command listed won't reproduce the problem. The second will. (I suspect its because the first is lacking that that is present in the second.)
Also, setting this to may provide an easier workaround for this speciifc bug than a full clean:
(The aforementioned setting was moved into rustbuild in )
I am getting an increasing feeling that we need to document and simplify the bootstrapping process better...
My hope is that once PR gets into the beta-channel, then we should not see this particular problem arise. I would like to know if anyone is seeing other warnings that are not covered by the cases I handled in PR .
This is fixed now, right?
I haven't encountered it since
Same here. Seems to be working. Thanks
closing as fixed.


Fixed on my end as well, thank you all!
Seeing this one here: ie. I attempted some kind of whitelisting just as you did in PR , but I'm thinking it will only work if I attempt recompilation with a rustc that has that whitelisted already?(which would explain why it keeps failing as if whitelisting it had no effect, ok definitely placing garbage instead of the below patch(which should compile fail) does have no effect which says that it doesn't get compiled before the above fail) Either way, I'm not sure where to Whitelist it, since it appears as too: (notice how the filename moved: is now ) Something extra: If I put in (which overrides the stage0 rust / / ) then it compiles ok the first time(as expected) then if I interrupt it and then attempt (re)compile, I get now:
This keeps happening to me with this:
I'm reopening and nominating for compiler team since it seems like it may be worth discussing to see if there's some principled solution for bugs like this. I think we've seen the last 2-3 releases all introduce at least one case of unused attribute errors in libcore/libstd during incremental, which is not great. Maybe there's some way we can stop tracking the rustc-perma-unstable attributes as 'green' in incremental? That may be too big a hammer though (or maybe too small). At least, it seems worth bringing this up at pre-triage.
This keeps happening to me when switching from to . Very annoying to have to . :(
triage: P-high, leaving nominated in hopes of discussion in a near term meeting.
There is a way of dealing with side-effects in the incremental system. We use such a solution for diagnostics. It could probably be expanded to unused-attributes if there is no cleaner approach.
removing nomination label; I'll follow-up with directly on ways to resolve this. (And/or discuss removing lint with )
Should we just demote to warn-only at stage0? It's getting pretty boring to nuke every time I rebase and something has changed in libstd (looks even more frequent nowadays), and I've heard people say they don't set in because of these "unused attribute" errors, which is a shame.


IMO should be the default for dev builds, although there's also the wasteful duplication between build artifacts and incremental dirs (for which I've just opened ).
Opened for the "temporary workaround".
Just FYI, landed, please leave a comment here if you still hit this issue. (it might move from libcore to other crates, not sure)


The message for E0139 suggests replacing with . Actually performing such a replacement will result in double drops, since the version consumes but the version does not. (It presumably needs a or something.)


On currently nightly, I get: () Yet the description for this error was merged weeks ago:
cc , in the future when adding new diagnostics mods be sure to add a call


The compiler seems unable to determine that two types are equal. I tried this code: I expected the program to compile and run without issue, because is , so the call should be fine. Instead, I got this error message: The problem exists on stable 1.42 and nightly 1.44
It somehow compiles if you replace the associated type with a type parameter:
cc /
Possibly relevant rustc log entries: Seems like the will resolve the inference variable to yield , but for some reason is unable to normalize that further.
It seems like the opaque type has a substs with only in it; on first glance I'd have expected the projection there, but the docs on do explain this: So it seems like the is what was inserted for the type parameter, making . I'm not sure why this is represented like it is, but it seems like we need more info to be able to look at the real substs of the opaque type.
Duh, I forgot how opaque types work. Not sure where would be stored (? It's empty at this point according to log), but it's definitely not in the type, so this output makes sense.
This is fixed on nightly.


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! And nominating for compiler team prioritization.
Miri fix:
This appears to be fixed
We fixed it in the Miri repo but have not yet updated the rustc repo for that. Let's keep the issue open until that happened.
Apologies! Where should I check in the future to be sure it's fixed?
No worries. :) You can check the toolstate page: https://rust-lang- (Or you can skip these miri issues if that's easier for you; I think I am taking care of them quite well -- though more eyes and more help are of course always appreciated.)
Thanks, gonna bookmark that. I was going through unlabeled issues which is how I stumbled here.
Hm, we could maybe have the bot that creates them also automatically apply "A-miri C-bug" or so... Cc


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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!