<!-- 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: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.


<!-- 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. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.


Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:


<!-- 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. --<!-- 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
Is this related to ?
Nope
Ooh I misread the Typerror ice, my bad :upsidedownface:
No big deal, this has to do with a lock (well, refcell) being held in hir typeck, if you're curious


If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim


<!-- 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. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet.


Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim


I encounter an ICE: with rustc 1.41.0-nightly ( 2019-11-29) running on x8664-apple-darwin when compiling The same code does not ICE when using nightly-2019-11-27-x8664-apple-darwin Sorry, I haven't taken the time to make a minimal reproduction example.
Can you post the ICE message and backtrace?
Certainly! Although it is not the best stacktrace I have ever seen. Backtrace:
Backtrace:
modify labels: A-mir
I think I have a clue here: First the code: The problem seems to be a partial move of together with async together with a generic type (if we replace by for example, rust will complain as well and no ICE). If we remove the rust will complain: modify labels: +A-async-await -E-needs-mcve +E-needs-bisection
Regression in cc modify labels: -E-needs-bisection
triage: has PR. P-high, removing nomination.


The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed


According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.


From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.


Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.


The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.


I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.


<!-- 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 first check the RHS, before suggest adding . It should also avoid suggesting when code is invalid. Thanks. Something like this should also not suggest adding : cc <!-- 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 --
I'm not convinced the second example should be something we need to fix, but the first example should be very easy to fix.
claim


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.
Fix is on the way at


I spotted this in : the result links to ' which is not a valid link. Cc
cc -- I think these are supposed to be autoredirected in JS?
Okay... This happens because there's more than one and the one we want is currently named . The URL escaping is fine; the -35 is the problem.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc


This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc


The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).


<!-- 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 expected to see this happen: Compiles successfully 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it


Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?


<!-- 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. -- <!-- 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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.


Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.


Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug


I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by


root: updns-0.0.6: v.
triage: P-high. Nominating for discussion.
self-assigned for investigation in short term (as in, next two or three days). However I suspect someone from will be a better choice to investigate this.
We should try to bisect this
used . Determined: searched nightlies: from nightly-2019-11-26 to nightly-2020-01-03 regressed nightly: nightly-2019-12-01 searched commits: from to  regressed commit:
is a rollup commit of the following PR's: I'm guessing this is due to PR
I'm still working on reducing this down to something that I could put into the playpen. However, one interesting thing I've found locally during my reduction: This version of the will signal an analogous compilation error: but if I lift the first argument out to a separate -binding (i.e. change it to use above, or the sub-expression out to a separate -binding (i.e. change the argument expression to use above), then the error goes away. I'll admit that I don't know all the details of how the fn-transformation works to support , but I strongly suspect that if this kind of local code change can make an error go away, then that represents a weakness somewhere (either in the fn-transformation, or in the borrowck).
Okay in the details block is a standalone version suitable for the : <details</detailsand the error it generates:
So this does seem like somewhat clear (expected?) fallout from PR : a use of a in a generator witness will be recorded as a unsafe pointer , and then is never , but the method requires that the task you give it is . I believe we can readily update the crate in question to avoid using the in the expression under the RHS of . But I do wonder whether we can/should improve the diagnostics here to try to guide the user towards such a solution ...?
I might have worded this too strongly, and/or over-reduced my example. In particular, its easy to move around the access to . But the borrow of may be trickier to deal with.
I'll have a look at addressing this with another approach I considered for . If that doesn't work out then I'll have a look at the error message.


The patch linked is enough to fix the crate in question, but I'm all for finding an in-compiler solution if we can do it soundly.
OK. I'm going to write some things up because I've changed my mind a bunch of times about how/if this can be fixed in MIR building and I don't want to keep forgetting things. Generators store values that if their value needs to be preserved across a yield. These values need to be visible for auto-traits, for example a generator may be resumed on a different thread after it yields, and so cannot be if any of theses values isn't . There are two passes that determine which values can be included in the generator: A pass that runs as part of typeck that walks the HIR to find the types of expressions and then checks for yields in the values scope (as determined by the RegionScopeTree). The types recorded here are stored in the GeneratorWitnesss type contained in the generator, which is then used for auto trait checking. This notably uses the types of expressions that HIR sees. The MIR transform that lowers the generator to a state machine. This determines the values that the generator actually stores. As a check for the compiler, we assert that any types that we capture here are included in the witness type (we don't know all auto traits, so can't check only for them). After statics no longer have a special representation in MIR. They are instead lowered to a dereference of a pointer to the given static: is lowered as if it were: Which becomes: The example above is somewhat deceptive in that the temporary that holds the pointer is used immediately after it's assigned. In this case it cannot end up in the generator since it's not live across any user code. However this isn't true in all cases, index and match expressions allow running user code while the pointer is live: In these cases MIR has to put the temporary pointer into the generator state and promptly ICEs. The obvious solution now is make type checking record the new pointer types in the generator witness in these cases. Unfortunately HIR is not a great tool for specifying "these cases". The methods that the region scope tree provides in HIR are either usually far too large (the "temporary scope") or occasionally too small (the "enclosing scope"). went for the sound but rather approximate approach, leaving us here.


One idea might be to try changing MIR building so that the temporary is never live across user code. For example, one might change the lowering as follows However working out how to do this for in a reasonable to implement way is harder. MIR actually already contains an escape hatch for values that are in the MIR but aren't in the HIR in the form of a flag (called ) on the variable. We currently use it for drop flags and boxes created by expressions. It's unclear what exactly the difference is between is. I guess one could argue that auto traits are for layout introspection and this would be further breaking that. I think that's everything for now.
Visiting from triage. were you planning to work on this further?
It's definitely tempting to take advantage of the constraints around statics to just declare these equivalent, and use the flag to get out of this. While I don't see any soundness issues around that, I also don't quite trust myself to get this right :) Can you expand on this? I'm not sure I follow.
Another solution that comes to mind relies on the fact that these pointers never need to be stored in a generator. They are consts, and the temporaries containing them shouldn't ever be mutated. We could add semantics for "const temporaries" to MIR, and never store them inside generators. The semantics would (hopefully) be simple: defined once and assigned a value that doesn't depend on any other temporaries; never mutated or borrowed mutably. We can move the statements defining them to the top of the function inside the generator transform. But that would be adding more semantics and special casing to MIR to fix a change which removed extra semantics and special casing, so I'm not sure if that's what we want :)
The argument is that the given the following auto trait we guarantee that if then there are no raw pointers directly stored in an instance of . If we make that guarantee then using internal in generators would not be OK. I would argue that we're not making such (or really any) guarantees with user defined auto traits.
Yeah, I don't think auto traits should expose layout implementation details of generators. And this really does seem like a pure implementation detail -- it doesn't have any bearing on what kinds of (unsafe) operations are allowed on a generator, like a self-reference would.


cc
So, I've been putting off commenting here to let these ideas sit, but let me leave a comment. I think I've reached a conclusion. TL;DR. I think we should mark these types as internal, but I think there are some better options for fixing this in the medium term, and this interaction should be taken into account as part of the "MIR 2.0" effort to rework places. Auto traits weren't really intended as a tool for probing layout, but rather semantic considerations. This is why traits like can be implemented by users. So I don't really think that auto traits give any sort of guarantee about their layout. Rather, this question is about is simply "what are the constituent types exposed by a generator", and this should correspond to the types that user code can directly access. The raw pointers here are not directly accessible. The values that are accessible are the "live values" that the user's code may later use -- and of course the code currently makes the constituent types be a superset of those, based on the AST structure. Of course, the real root cause of this error is a simplifying change to the definition of in MIR. It used to be that a Place had this grammar: but now we changed to just , which is why we are required to introduce the new temporary (and that holds the address of the ). As we've been talking about this change, I've been saying that we should be considering the older definition of as the one that is used by various analyses (and in particular by borrow check). This particular transformation of removing statics doesn't affect borrow check, but we failed to take into account the fact that the set of live variables can effect the definition of what is live in a generator. In particular, compiling for some expression requires a temporary unless corresponds to a place -- those places used to include statics like , but they no longer do. But I think that for analysis purposes, it should appear as if they do. We could fix this in two ways. We could write some code motion / duplication that takes temporaries like that are live across a yield and creates a fresh variable after the yield. The idea would be to make them never* live across a yield.


We can do this because that operation is a compile-time constant, really, and thus the value doesn't need to be live across a yield. This might be worth doing as a size optimization regardless. Secondly, some of the proposals we've been kicking around for going further with simplifying include the idea of a distinct sort of temporaries that explicitly represent a "partially constructed that hasn't been used by the user". The idea was to allow borrowck (and other analyses) to trivially reconstruct the . We might want to add this interaction with auto-traits into the consideration for that design, and maybe it takes us some place (e.g., these special temporaries are not considered live for the purposes of auto traits). Having written out both of those options, though, I sort of lean towards the first, at least for this specific issue.
I think these references and raw pointers created by MIR construction should be marked as . They are not visible at the language level. They can be viewed as just prefetching the address of a static, so the compiler could pick any type it likes for it (, , , some compiler internal type) so it must not affect auto trait inference. Drop flags are ignored for similar reasons. You cannot use an auto trait like this to detect them: So I think that should be reverted and the temporary static references should be marked as .
Note: opened instituting this change and I r+'d it, since fixing the regression seems pretty important and time is of the essence; there is general consensus here on the thread; this is only restoring older behavior. In particular, there were some suggestions that this might be a lang team issue; I think there is some 'intersection' and I don't want the perception that I'm trying to shortcircuit discussion. That said, I also think this is primarily a compiler team matter, since it's a deviation from the old behavior, and further this deviation was caused by altering the MIR away from the "natural, Rust-based" definition and towards a lower-level definition.


A simple malformed macro makes the compiler crash. Code: Playpen error: Playpen:
Another case: Playpen:
I had a crash in a bad macro which hits the same bug as Note that his/her error has the following which is a different stack trace: I'm on the latest beta; not nightly.
I think you and I are getting a different panic from this bug. I've opened since the panic is in a different location in the code.


<!-- 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. --<!-- 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
label +F-dyn_star
:laughing: the code thinks that this is a upcast, I think, rather than an unsize coercion. shouldn't be too hard to fix, but I may leave it for someone else. edit: nvm I'll just fix it.


I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .


I tried this code: When I run it under , I get this: Creating a reference from such pointer looks suspicious indeed. I could send a pull request that adds a condition there, but I want to ask first if this is being done because „we are , we can“, or if this is something that really should be fixed. : (but I've looked at the git sources and the thing is still there) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it should only be UB to dereference the pointer you get from , so I'm not sure why Miri thinks there's UB happening. Just in case, prioritize
Because that pointer is being turned into a reference to feed to internally. And references are supposed to be always valid.
Looks like fixed this for but missed it in .
Yes, seems this needs to use .
I renamed the issue to reflect that the bug is actually in (which calls).
Cc
Assuming you use the default flags for Miri, that change should not be required to make Miri pass, so I'd be surprised if doing the same change for would make any difference here. If it does, that seems like a bug in Miri that I should investigate.
Ah, but the in is indeed a problem (the PR was mostly about so I got side-tracked; the is what should not have any effect here). Miri ensures that references are at least dereferencable, so yeah that would explain the problem here. Good catch!
Yep, I apparently missed this somehow in . Fixing the indicated line to use should be enough to fix it; I'm preparing the patch currently. claim
Hm, Miri still complains, even after the fix landed... it seems Miri doesn't like being called with dangling pointers. I'll have to look into this.
IIRC, when , I changed the type of the intrinsic to take a raw pointer rather than a reference, but miri wasn't touched, so that would make sense miri's still expecting a proper reference.
Patch arrived really fast, we are assigning "post-mortem" a priority of as discussed as part of the and removing .


We need to add an epoch lint for It will lint , suggesting removal in root mods, and replacement with in non-root mods. This is blocked on the ability to elide extern crate in the first place.
It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards:
cc
I think the lint should be by default off in cases with , such as: This is because of the ergonomics problems with macros and the new macro import system, expressed here: It's bewildering for the migrating users if a lint tells them not to use the syntax, but then finding out that many of the macros out there have downright bad ergonomics with the import syntax. (For clarification: I think this is an undesirable state of affairs, and we should be linting against all , but if we do that, the ergonomics problem with the macro import should be fixed somehow.)
I don't think we want at all, really. If we want to import macros, we should have another means of doing it. Otherwise we have an inconsistency. So yes, I think I agree with your last paragraph above all,
I've discussed this a bit in the tracking issue for the macros import system:
Thanks, you expressed the exact concern I had in a concise way.
Another thing this needs to lint is unlisted crates that are included in that clash with existing modules. I'm not quite sure on what the story needs to be here cc
Does it? I've thought one of the things the path clarity RFC was about was to have separate namespaces for top level modules and extern crates.
The current plan has changed a bit so I'm not sure if that is still true. (If stuff does change it will probably be RFCd again, there's a bit of experimentation going on)
Sigh I hope we won't discuss all of this crap all over again... I don't enjoy that but it is not me who wants to change things.
I've hidden your last comment, which I found hostile and unconstructive.
IDK what has been hearing, but for me, this is the latest state of consensus on that issue, and it seems to have separate namespaces: is that the case? You seem unresponsive on IRC that's why I'm using github.
That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc. Everything has been implemented.


We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.


Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.


The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !


Rustc used to be able to replace with a constant when optimizing, not at the moment. It simply looks like a Layout method that is not inlinable. (This is a regression strictly speaking — stable & beta can do this optimization, but not nightly.) Code to reproduce:
Are there any ways to write automated tests to check for "regressions" like this? Assertions against LLVM bitcode?
Yes can be used for this, e.g. Assuming this is run against the bitcode after optimization, that is.
cc -- seems LLVM related
Nope. Just () that is not marked as inline.
cc
I didn't confirm that making Layout::repeat as inline fixes this, so please confirm that/add a test before closing.


<!-- 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: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .


The and traits contain convenience methods and wrapping and . This issue tracks addition of similar methods to trait's and . This is implemented in .
if this is a tracking issue, maybe it should have the label
We should eventually add similar methods to .
I know nothing about developing on Windows so I can't do it myself but I guess a PR would be accepted. Can we stabilize this? Is there anything that still needs to be done?
Seems reasonable to me! 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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
What's the next step? Should I make a PR to stabilize? Sorry but I don't fully understand how things work yet.
indeed that should be all that's necessary! If you'd like to make the PR you're also more than welcome to do so!


Having written Python for several hours, I made this mistake and couldn't realize what was wrong for a while. No response claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not sure whether it's worth to fix this right now. will significantly change this code, basically requiring a rewrite of this diagnostic.
Agreed, it's reasonable to wait for type ascription removal. Thanks for the info!
Now we should fix this error message: is not OK, we'd better suggest to use . I think you need to add proper logic for this part of code:


<!-- ICE: Rustc '' 'error: internal compiler error: named field access on non-ADT', 'error: internal compiler error: named field access on non-ADT' 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: 22 | let buf: &mut [*const dyn Foo] = &mut [&u8, &u8.0, &u32, &u32.0]; [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
mmh this bisects to cc


with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:


0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.


22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.


Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:


No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.


, and a few others have summaries as given in the source code, but , and a few others somehow don't. This is perplexing when we recall the method impls are generated by macros
cc I'll try to take a look in the next days.


<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- 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. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.


(cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.


(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.


When confusing a Fn-like struct with a regular struct in an pattern, the output leaves a lot to be desired: <details<summary<a href=""Current output</a</summary</detailsWe should probably collect all these errors into a single diagnostic error: Even better if there was only one diagnostic.


On linux, , then run: This changes the permissions of to . Is this expected? masks away everything other than the lower 3 triads when it calls out to this code: Then sends these mode bits into into chmod which considers four triads, not three. Possibly useful references: and Should we change Metadata.permissions to preserve that triad, maybe by masking with instead of ?
I guess the solution depends on whether Unix's std::fs::Permissions is supposed to care about 9 bits or 12 (this is not an implementation detail since it's exposed to the programmer via of PermissionsExt). any thoughts on this?
It seems to me like we should extend the mask to the full 12 bits.
Seems reasonable to me to avoid masking where it makes sense!


Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.


Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?


Update test file to use + annotations instead of (see https://rust-) The files need to update are: - <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
is the correct file name , not ? And what about this comment?
Is the problem fixed ? If not, I would like to work on it !
WIP PR has been closed due to inactivity so you can work on this.
I would like to be assigned to this issue. Am I supposed to do a new pull request ?
claim Go ahead!
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
Hmm, it's odd, anyway, you can assign the issue to yourself by comment Ah, I mistaken the command, the collect one is , sorry.
claim
If I understood well the problem: I must replace all the by just , even if comment exist ? Because the output changes, I should modify the .stderr version I must change with in , and as should raise an error we add why add in the version ?


See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial: OK OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () Cheers
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()


cargo is relying on the to find rustc, but if one runs cargo with , cargo will error out with the unhelpful: cargo should detect this and return a proper error message for this. A proper workaround for this is to make sure that has an absolute path to the binaries set, as in: It needs to be absolute because cargo does a chdir to the build directory, which would break a relative path.
We have a function, that cargo can use to determine the path to itself, then use to launch the corresponding rustc.


Instead of just saying the key can't be verified, explain why.
Yeah, it should also not fail! Missing gpg is a warning condition, not an error condition.


Note: the below reduction originally came from a + in the wild. I haven't found a way to demonstrate this outside of the "float inference vars + method" combo, but: works on stable () and beta (), and errors on nightly with: Even though it doesn't show the source for candidate , I'm almost certain it's this: from (cc On the original PR I left comments like , trying to rectify the issues with the original approach, but they didn't go anywhere and the version that one in the end is the (arguably) more fragile original one, that uses blanket s and works around their unwanted interactions. It's possible in this case all it takes is checking for "float inference vars" and making sure they can never be considered to implement , but I'm worried there might be other edge cases lurking in the shadows. Also, did both of those PRs skip crater? I feel like this shouldn't be that hard to hit in the wild.
WG-prioritization assigning priority (). label -I-prioritize +P-high


The "Install MSYS2" step of failed, but the build kept going and failed later with obscure errors. We should fix this so that if msys2 installation fails the build fails immediately!


crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.


Repro: As of current nightly: This is the unreachable line: The same crash reproduces back to 1.47.0. Older stable compilers do not crash:
Bisect: searched nightlies: from nightly-2020-07-10 to nightly-2020-08-27 regressed nightly: nightly-2020-07-22 searched commits: from to regressed commit: () Mentioning because appears the most relevant.
Assigning .


I tried this code: I expected to catch lint and suppress it, as it should. Instead, compiler issues a diagnostic both about unused value and unfulfilled lint expectation: It does work as expected though if is applied to function. I used the latest stable (Rust 1.81), but it is reproducible both on latest beta (2024-09-04 ) and latest nightly (2024-09-05 ). labels: +F-lintreasons, +A-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This issue is not limited to just . Others attrs like or don't work either. For instance, the following variant of the reproducer with replaced with emits the warning even though it shouldn't: Playground: This broken behaviour goes as far back as at least 2021 (couldn't build and test earlier rustc) We emit the lint on the HIR node corresponding to . However, the or levels, which are supposed to override the default level of the lint, are associated with or bound to the node underlying the as shown in the figure below: The end result is that the lint's level is never knocked down to or since when searching for levels we start from the node on which the lint is triggered and go up the chain of parents. So in this case we look for the level on and then on the and so on. We never look for it on the where the levels actually exist. As it happens in the lowered HIR does have the / attrs for both the node and its child node. However when adding the levels in the we do not add anything for the node as shown here (note the comment): If were to add the level for as well the issue will go away. However, if we do that we will still have one problem in the case of which is that we will end up with two expectations and the one on the will not be fullfilled and hence we will still see a warning about unfulfilled expectation. To prevent that I think we should take the following approach: when an attr like or etc.


are present for more than one HIR node in the and if one node is the (direct or indirect) parent of the other node, then add the level only_ for parent node. This will take care of any lints on the child (since we always walk up the HIR hierachy as mentioned earlier) as well as the parent and it will not cause any warnings about missed expectations. I am new to this area so if someone can review this idea or suggest alternatives that will be great. since you seemed to have worked in this area recently, can you please weigh in?
Your investigation is accurate, and the fix is simple: visit the statement node when building lint levels. Do you mind making such a pr ? I don't think we need any special adjustment for cases, duplicated attributes are already taken into account, but a test won't hurt.
Thanks . Yes, I'll put together a PR. My only concern is if all we do is add the level at , although it will work perfectly for , etc., in the case of we will end up with an unfulfilled expectation on the node which will appear to the user as a warning. But anyway let me have a go and see what happens.
Opened draft PR that adds the lint on . It does suffer from the extra warning problem.


Tracking issue for rust-lang/rfcs.
Is anyone working on implementation already? If not I can take a crack at it.
I'll probably do it.
Huh oh, we have an issue already: do we mean to include potentially minus-prefixed literals? If yes, we have a problem because 1. it means we have to return an Expr instead of a Lit, which means I'm not sure one will be able to use the bound fragment in a non-expr context (for example in a static array type?) and 2. it's no longer always a single-TT, so the benefits in terms of future-proofing are a bit less good. If we don't... well, we loose expressivity. I have no idea what is more intuitive though... Would you, as a Rust user, expect to parse ? I certainly can think of use cases for this...
good point. I think I would have expected it, I also agree with the complications.
Can't we upgrade Lit to support negative literals?
I'd expect "literal" (or a future integer-literal specifier) to include (negative 5), but not (the negation of positive 5). Perhaps that expectation doesn't match reality, though. For instance, based on parsing rules for non-literals, I'd expect to act like . So, if handling both and as literals makes this easier, that works. But "literal" definitely needs to include negative numbers, or we'd have a weird user trap to explain.
I'd expect "literal" (or a future integer-literal specifier) to include -5 (negative 5), but not - 5 (the negation of positive 5). Unary operators, including minus, are processed purely by the parser at the moment, no lexer involved. So their treatment is whitespace agnostic. (I personally think this is a good thing.)
I agree with is not syntactically different from and has no reason to be. But I also agree with the fact that the user will probably expect negative numbers to work as literals (even it – syntactically – they're not).
is also supported in literal patterns while arbitrary expressions are not. It'd be reasonable to support it in fragments as well.
Another thing that won't match is a macro call, like , or any of the other macros that I think of as expanding to a literal (, ...).


I dunno, maybe this is not such a good idea after all. Re-reading the RFC in a more skeptical light, I felt like the "Motivation" section could use some more concrete use cases. Maybe this is just failure of imagination on my part, though! I think the likelihood of this feature attracting people who really want constant expressions should be acknowledged as a drawback, too.
That's fine IMO. Personally I'd like it to match only explicit literals in code to distinguish, for example, between literal and identifier and produce different code for them. Right now this is not possible because all of , , are too broad and conflict with each other.
Hi All, I have implemented this feature in my fork of Rust over 1.25.0, under this branch: Following a quick review by a rustc mentor I may have the free time to provide a full pull request for this.
BTW label has the tooltip "implemented in nightly and unstable" but I did not see it there, i.e. commits & pull requests referencing this. Did I miss it?
The implementation that I worked on was merged, yay!
Is there anything stopping an FCP for this?
It's currently merged in unstable; do you mean an FCP to declare it stable?
Yes, an FCP to stabilise. Should have clarified.
Currently, it is not possible to pass a literal from a macro to another macro. . I think this is a bug.
Interesting! That is a bug. I opened to track it.
Agreed, this should be allowed just like passing any other node types.
Is there anything else preventing this from being stabilized? The issue above has been fixed.
This has baked for some time now and I believe it should be ready for stabilization. So let's start the review. merge The feature gate test is here: Unstable book: Tests defined here:
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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!


See for info about what commands tagged team members can give me.
Reading through the tests, I see that is a literal. While that makes sense to me, I remember hearing that it wasn't, but was instead a negation operator and a literal. Am I misremembering?
cc on
I agree that it makes sense. I would say that even if is interpreted as negation + a literal, I would probably still want the macro matcher to accept since that behavior seems more intuitive. In other words, I would see being more as an implementation detail than what a literal is in the mental model.
I think that the nuance with causes a bit of a problem, because I don't think it should be treated as a literal, but I also don't think that the current implementation of would allow detecting it either. You could naïvely allow but that would allow which is clearly wrong.
there are tests currently implemented that verify that is detected as a literal.
I worded that wrong; I meant that only having a matcher and not being able to distinguish strings and numbers means that you can't easily make not a literal.
for procedural macros the input as lexed by the compiler is (two tokens) but procedural macros can create tokens that are negatives (like ). In that sense matching for makes sense to me.
Are literals generated by the compiler counted as true literals? A quick example would be something like: This fails to match, as the expansion, I guess, happens after the selection. I just naively assumed that would have worked.
is not a literal generated by the compiler, it is an identifier followed by an exclamation mark followed by a set of parentheses containing some tokens. See for example: If you were to use it in expression position, it would be interpreted as an invocation of which expands to a string literal. In this case and in your macro though, it is never in a syntactic position where it would be treated as an expression.
I can understand semantically why it doesn't make sense, I just thought it would have, but that being said, I already changed it to , so there's no issue. It just made more sense to me as a literal, because according to the compiler, it could generate a literal from it. I guess it was more a question than an actual issue.
This is true, but there's more to it!


A few built-in macros can expand their arguments eagerly through ~m a g i c~, so they accept and likes even if they expect string literals: Fortunately (or not), this currently cannot be done in user-defined macros.
I actually just realised that I can't change it to , as it's used in . So, I've just had to manually unroll the macro. ! It doesn't look pretty. :( Ninja edit: I just tested what actually happens if you try to pass in a non-literal with . It rejects it the exact same way. Does the already make use of this feature? If not, the seems to propagate the required token. Oh, unless the compiler steps in... That's actually probably the case... I've reverted it back to the type.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Since you implemented this, would you be willing to write up the stabilization PR?
sure
This appears to be missing from the Rust reference


<!-- 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. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +S-bug-has-mcve
I'm having trouble understanding this ICE. Could someone point me in the right direction? Thanks for your help!
release-assignment I'm finding this quite hard. For anyone else: I suspect is responsible.


The fix for CVE-2022- (, ) appears to have introduced a regression that can cause file system corruption on some UNIX systems. The new code will attempt to use in any case where it does not know what type of file a directory entry represents. Some systems do not provide that information along with the entry names returned while reading a directory, and even on systems which provide a type hint, that hint may be . In cases where we do not know the type of the entry, the code tries first to unlink it as if it were something other than a directory: The code assumes that on a directory will fail with , or on Linux with the non-standard , but this is not always the case. POSIX does suggests as a failure in some, but not all cases: (See in The Open Group Base Specifications Issue 7, 2018 edition) Implementations are not required to prohibit on directories, and indeed UFS file systems on present day illumos and presumably at least some Solaris systems allow of a directory if the user has sufficient privileges. Other platforms may as well. Unfortunately unlinking a directory on UFS causes a sort of file system corruption that requires an unmount and a trip through to correct. Any code that uses on UFS has since started causing that kind of corruption, which took a bit of work to track down. I think the fix is probably relatively simple, and has the benefit of not touching the code path where we believe we know what sort of entry we are removing: In short, we should try to first, rather than first, as that always fails in a safe way that we can detect. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc (as you're the one how wrote the new code)
Thanks for the ping claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Was this issue reported upstream? Filesystems corrupting themselves seem like a poor failure mode in any case, and in some ways is a violation of the sandboxing that the kernel ought to provide for the user-space applications.


It was reported upstream, and we're working on a fix -- but that fix will obviously only be in new versions of the operating system. To expand further on the corruption: the file system becomes inconsistent and requires repair, and the damage such as it is can only be caused by privileged users; i.e., by root or a user with root equivalent privileges. I am not yet aware of a way that it would cause actual data loss, just an interruption to service, but anything is possible. Allowing the linking and unlinking of directories is a regrettable, but seemingly intentional feature we are saddled with through our UNIX heritage. I'm working to disable and eventually remove the feature in the OS -- although we strongly value backwards compatibility, in this case I can't really see a legitimate use case or find a consumer that would be broken by doing so, but we won't know for sure until we try. While this specific case is unfortunate, and we can and will work on our end to try to mitigate the impact, the fact remains that POSIX explicitly documents and allows for implementations where on a directory does not return . For the code to be completely correct on all POSIX systems, it cannot make that assumption. In addition, working around the issue in new versions of the OS doesn't fix existing deployments out there already. Enterprise customers are often reluctant to promptly update their operating system, even though they may update software built and deployed on it -- software that may be written in Rust. I myself hit this issue by upgrading only the Rust compiler to a new stable version, and trying to build and use Rust-based software we have to build UFS ramdisks on illumos. We aim to fix the OS for the future, but the critical regression in Rust needs to be fixed as well for the present. We appreciate everybody who has looked at this so far -- please let me know how I can help expedite the process!
Thanks again for the report. The linked PR should fix the issue. Apparently only and guarantee that trying to a directory fails. , and allow it, at least in theory. After looking around a bit I found that it is even explicitly documented for and . So it is not a bug but a feature there... After changing that in you might want to adapt the man page as well.


We can try to avoid this case by default, as is switching to try unknown as a directory first, but you should note that this is still going to be racy. If there's an unprivileged adversary like the CVE supposes, then they can try to race changes between "try (and fail) as a directory" to "unlink as a file", to make it unlink a directory after all and induce corruption. IOW, it sounds like it's not safe for a privileged process to unlink paths at all if they may be changed by lesser privileges .
It should not really cause corruption according to the , just orphaned directories: Of course this can lead to resource exhaustion since the disk space and the inodes cannot be reclaimed until the next .
And that user is only root or otherwise root-like? i.e. it's not just talking about regular access privileges?
For Illumos the process must have root privileges or needs to be in the process privilege set (). Solaris has at some point abolished this privilege and apparently does not allow unlinking directories anymore ().


There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.


But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in


<!-- 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: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --It should name the traits are attempted to be coerced, maybe tell me why that's not allowed (yet), etc. Right now it just highlights the entire line. The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed". Note that I understand why it's not allowed, I was just disappointed by the error message. I already talked to about this, and they also thought this output may be problematic. Even though the feature may be unstable, it's quite easy to arrive at a situation where you may get this error. <!-- 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


<!-- ICE: Rustc '--crate-type=lib --edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --code: 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
Regression in nightly-2023-02-12 found 8 bors merge commits in the specified range commit[0] 2023-02-10: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2023-02-10: Auto merge of - JulianKnodt:arrayconstval, r=cjgillot commit[2] 2023-02-11: Auto merge of - BoxyUwU:deferredprojectionequality, r=lcnr commit[3] 2023-02-11: Auto merge of - Dylan-DPC:rollup-fkl9swa, r=Dylan-DPC commit[4] 2023-02-11: Auto merge of - petrochenkov:doclink2, r=oli-obk commit[5] 2023-02-11: Auto merge of - the8472:rawvec-simpler-layout, r=thomcc commit[6] 2023-02-11: Auto merge of - matthiaskrgr:rollup-qnn380r, r=matthiaskrgr commit[7] 2023-02-11: Auto merge of - cjgillot:sroa-const, r=oli-obk ERROR: no CI builds available between and within last 167 days maybe ? ping


It looks like that when a local variable is initialized in a loop and dropped in the same loop, the stack local drop flag for that local isn't reinitialized to "not dropped" when the loop runs after the first time. Concretely, this test passes on stable and fails on nightly right now: cc
Interestingly this slight variation on the above code does drop twice as expected:


I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.


Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.


<!-- 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. --<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in


This somehow doesn't occur when putting the function in a non crate, yet I can't find any difference between the version of and this one. () Errors:
Seems like it panic when the trait is not found: Maybe it can use  instead.


I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
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: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- 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 occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.