Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.


Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).


I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.


Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.


I suspect and have a more concrete notion about this.
I don't have anything much to add to this despite it coming up for triage today. I think it has to be fixed still, I'm still happy to do it via whatever combination of static linking by default and use of is sufficient for packagers, and I haven't seen any clear movement on it in the meantime.
accepted for backwards-compatible milestone
I'm getting worried that we won't resolve this for 1.0. I agree this is important to fix. Here's my current suggestion: Modify the build system to once again set LDLIBRARYPATH/PATH to find the appropriate dynamic libraries. Add a flag to rustc to disable rpath Add a configure flag to disable rpathing the rust build itself. Packagers can use this to do whatever they want. With this logic the rust package itself could avoid rpath where distros have their own way of dealing with library paths. The rustc installed by these distros would still be rpathing user's crates for the sake of convenience. Is this an acceptable compromise or do distros want us to completely disable rpath? I'm afraid that doing so would provide an inconsistent developer experience depending on how rustc is acquired; if we need to do that then we instead must find a way to completely eliminate rpath.
If we start to just statically link everything by default then rpath becomes much less important and we can just say it's up to users to figure it out if they opt into dynamic linking.
I think we should completely remove absolute rpaths. It's okay to have $ORIGIN-based ones but it may not be a good default. I'm not sure what the answer is to that, but agree that static linking basically resolves this.
It doesn't appear that this is fully working. There are still rpaths in the binaries when configured with even though the flag for rustc does work. /usr/bin/rustc: RPATH=$ORIGIN/../lib:/build/rust-git/src/rust/x8664-unknown-linux-gnu/stage1/lib/rustlib/x8664-unknown-linux-gnu/lib:/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
What steps did you follow to having the rpath show up? I thought I double checked on linux that the configure flag worked, but I may have overlooked something.


<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc


<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: on stable 1.78.0, this checks in 0.02 seconds. on beta 1.79.0-beta.3, this hangs somewhere in , I killed it after 5 minutes of no progress.
cc
Sharing the stack would be useful
:thinking: that doesn't really seem to be it
You need to switch to like thread 2 or 3 if you're doing this in gdb
it's not particularly deep, but it looks downstream of so I guess this must be it
Minimal:


Same error, with the last github version.
Also getting this, I'm running the Yosemite GM 1. Not sure if it's related.
I also getting this on MacOs
Still getting this make error, like many others did. Anyone want to fix this?
I have no idea how to fix this, other than just installing xetex or however it's spelled
The configure(or make) did find LuaTeX.
Sadly I don't have time to work on this right now. A simple fix would be to disable pdf generation unless specified in configure, or to require xetex.
I don't think that LaTeX should be a dependency to build a programming language like Rust.
it seems reasonable to have the option to not build PDF docs if you don't want to
I think I'm getting the same error, which is strange because I believe I was able to a couple days ago. In the log, the complaint is that is not found. As suggested above, is included with MacPorts' package and installing that allowed compilation of docs to go through.
will build without building the PDF docs


Error happened while working on updating closure capture analysis in rustc which is part of rustctypeck. The highlighted line is what changed between the build that broke and the build before it. <!-- 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. --Version reported in build log and similarly one or two more Complete build log: Build log with : Build directory: (Heads up, this is 29G tar, 39G extracted)
What was the exact build command that caused the ICE? If this is with , then I also see this issue every now and then. Locally built rustc all have the "dev" version string, which means it doesn't have to rebuild everything just because you do , but it also means it cannot detect that the ABI changed, so it might try to load old files with the new rustc and of course that will fail. I am not sure if much can be done about this.
Some potential duplicates: , , ,
I do . This happened to me again last night: The assertion is fired in the not the same line but the same file, I haven't gotten around looking at the query code to see what failed. Only thing I worked on since the last x.py clean (maybe 10-15ish builds in, though I could be wrong) was change closure/generator pretty printing (in rustcmiddle/src/ty/print/pretty), haven't rebased since. Though I can see that rustc builds are themselves are more prone incr compile errors, also didn't think had anything to do with the build process, otherthan maybe some version strings.
Cc I mentioned because one way to avoid this problem might be to embed the git commit in the version string used for rebuild detection -- but that would be rather annoying in many cases.
You can set ignore-git to false in and that'll embed git commit hashes. But I think that must only patch over bugs - it can't be necessary. I doubt it will fully fix this bug. I suspect the problem is that Cargo doesn't delete incremental state on dependency changes - which means that rustc must be prepared, currently, to see incremental state serialized by a different rustc... ideally, handling that in a way that doesn't just throw everything out, but even just not panicking would probably be enough.


See also
The proper way to fix this is to wipe the build cache whenever the stage1 compiler changes. That will make builds a lot slower, but it's better than ICEs and having to wipe the cache anyway. I guess we could add a --keep-stage1-cache flag if you're sure you haven't touched metadata - not sure how useful it would be in practice. said on Zulip:
Wait, I'm confused again. Why does the metadata matter other than the incremental cache? Cargo already invalidates the cache when is modified, which is why libstd gets rebuilt when you modify the compiler. Is there anyone not using that's been hitting this issue?
I found while working on that this is not true: if you use --keep-stage-std 1, cargo will blithely keep the cache for all crates in build/stage1-rustc, without rebuilding. Copying over my comment from
Another possible fix is to make rebuilding after a commit cheap enough that we can include the hash unconditionally. Right now it's used in rustcsession; if we move it to rustcdriver, that would only need to relink the .so and recompile the final rustdoc/clippy/miri crates, not their dependencies. I guess it means we'd have to suggest using keep-stage-std more often :/ but people are doing that pretty frequently already.
Oh, and it has the downside that if you're testing the project on external crates cargo will recompile them after every commit. Maybe that's a good thing?
The only time it won't fully fix the issue is when you're modifying rustc_metadata or similar and don't make a commit between builds. I'm ok with not fixing that case, because anyone working on metadata is much more likely to understand what went happened and how to work around it than random contributors stumbling into this for the first time.
hit this issue this morning with incremental disabled, so it's relevant to all metadata loading, not just incremental.
Thanks for pointing me to the right issue. Following Tried some commits from the past few days Would it be useful to keep going with this approach? Oh, and this is with .
That's helpful, thanks! No need to find more commits, having a reproducer at all is already very useful.
This fundamental issue doesn't just apply to bootstrap, right?


If one uses a locally built toolchain to build some crates, and then updates the toolchain, the same ICEs can arise (because the dependency rlibs will now be in the wrong format). Bootstrap is just where people run into it most often. But a solution inside bootstrap won't fix the fundamental issue. (E.g., it won't fix the Miri version of this problem, which got reported at )
Yes, that's right, any two toolchains that were built from different sources but have the same version string will have this problem (this is why we set a custom description by default in the source tarballs, so they won't reuse metadata from the official toolchain). Removing or defaulting it to would work for miri though, or at least make it so that you have to try a lot harder to run into the bug (e.g. twice with different local changes that haven't been committed).
A more "principled" fix would be to have something like a metadata version number embedded in the files that contributors are responsible for updating when the format changes. But I worry people will forget to update it, the same way people often forget to bump and that causes caching issues:
oh right, and suggested adding incremental to dep-info: but given that this bug is also showing up for metadata, not just incremental, I suspect that's not a complete fix:
Yeah, if we could somehow ensure that such a version number is always correct it would be a proper fix but manual bumping probably won't work. Unless we find a way to at least have CI fail when one forgets to bump...
reported seeing these crashes for , not just for tools and stage 1 rustc. I think he's running into this line being buggy: that shouldn't filter only to build, nearly all the commands read metadata and need the same treatment. Not making a PR because I don't have a test case yet, but if anyone comes up with an MCVE that makes crash, I'd be interested to see if this diff fixes it: also, I wonder if we could fix the original problem with metadata/incremental in stage 1 by applying clearifdirty to rustc too:
reproducer unfortunately gives me a different ICE than the one in the linked issue; it's for stage0, not stage1. So I can't use it to test my diff.


a while ago found that reproduced the issue; if someone could run that both with and without my diff applied to see if it makes a difference that would be helpful; I'm out of time for today.


It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).


Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/


Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.


While bootstrapping on Fedora 25 armv7l, I'm hitting a SIGILL when some beta-compiled programs are actually executed. This is with a purely default , no external LLVM or anything. On beta (exactly ), I get a little ways into stage1, and then build scripts SIGILL, apparently from double-panics. I reckon that the stable stage0 builds a stage1 compiler that's fine, then that stage1 starts building things that don't even need to execute until we get to a build script. Then: So I also tried the master branch (exactly ), and that fails as soon as it executes at the start of stage1. Here it seems that the downloaded beta stage0 compiler builds all of its stuff fine, which presumably includes executing some builds scripts like above. But the stage1 it creates seems to be bad: I traced through with gdb, and it's not actually crashing, rather the that it execs into. Here's the backtrace: That looks like a triple panic! The actual SIGILL is delivered for a instruction:
(side note: on the beta branch I have also applied , or else you have to configure with an explicit to get armv7.)
I tried to build a debug nightly, but it can't link to in stage0's librustcconstmath:
Looking at , it seems SIGILL is expected because of the . The questions are then, why did it panic in the first place and why did the default hook panic?
is where the default hook is panicking.
Yes, I agree the SIGILL is just a symptom of the nested panics, not something to fix in itself. While I couldn't get a debug build, I got a release build with debuginfo. Here's a better backtrace from running : So the first panic comes from the failed at frame called from . The line right before got a shared -- maybe something isn't marking this released properly? Then the nested panics come from trying to read this same broken , with frames and also trying to .
Looks like you are using an LLVM without the fix in . That will blatantly miscompile rustc and lead to severe problems.
While it does sound the same, unfortunately no, this is with the rust-bundled LLVM, including your fix.


:/
That said, there must be something local going wrong, as the official (cross-build) armv7 compiler seems to work fine, at least with the same simple reproducer, e.g. . I'm going to try a fresh build on a fresh system with absolutely no local LLVM present...
So -- that worked, both beta and nightly. I'll make sure to update our distro LLVM patches. What tripped me up on nightly was that stage0 is still 1.17.0-beta.2, which doesn't have the LLVM fix. I bumped that to beta.3, and then it worked. This doesn't affect the official nightly builds because only the host compiler goes through stages, and AIUI the cross-compiled targets only use the host stage2. But doing a native arm compile, the bugged stage0 gave me an unusable stage1. On beta, I don't know what happened before. I think perhaps somewhere when I was jumping between local and rust-llvm and testing different branches, I must have gotten a build of the still-broken rust-llvm, with a timestamp such that rustbuild didn't think it needed rebuilding on the fixed sources. I still have that build directory tarballed here, so I may poke at it when I get a free moment.
So we should update 1.18's stage0?
OK, see to bump stage0.


These are all legal, and somewhat strange, since they're not really following the file-system analogy that modules are typically explained with. I expect this behaviour is just whatever happens to fall out of the current implementation strategy, so let's make a more explicit decision one way or another. As one might expect, each of these is a distinct instance of (which can be verified by placing in : the compiler will greet you 3 times). Noticed in .
This seems weird to me. I think the intention is that the out-of-line syntax () should only work at the top-level.
I'd vote for allowing non-inline modules only at the top-level, to retain a clear mapping to the file system.
(Or nested inside modules.)
triage: P-medium Backwards incompatible, but ... kind of a curiousity.
Found one more mod aliasing scenario. It involves several files, and is semi officially allowed by the reference. The layout The files The copy module will be aliased. The problem is that although and are not directory owners, their inner modules are.
Upon reflecting more about this, I think that there are two questions here. should non inline modules be allowed (syntactically) inside items? should module aliasing (the same file representing two modules in the crate) be allowed? The questions are independent because you can use attribute to create module aliasing manually. I would prefer if the answer to the second question is not. I'm contributing to the Rust plugin for IntelliJ IDEA, and one of the tasks there is mapping files to modules (for example, to go to the parent module). I would much prefer just to highlight module aliasing as an error, rather then to deal with non one-to-one mapping between files and modules. As a side note, if a user does want aliasing for some reason, she can always use symbolic link for the same effect.
I tend to believe it is fine to have aliasing if you write the yourself (you asked for it...), and that it would be ok to put a non-inline module inside an non-module, if you specify the path yourself, but that we should error out otherwise. However, there has definitely been confusion in the past about the role of as a declaration and not a , and disallowing aliasing would prevent that confusion from leading to incorrect trees.


however is disconcerting, and suggests that perhaps the code has a slightly different model in mind than I do in my head. :) That is, I strongly expect to (by default) be found at . What happens if you don't have the , but just place in ?
It is forbidden because is not a directory owner.
Just in case here is a repository with the example: I don't see a reason to allow user to shoot himself in the leg. What if you accidentelly have identical attributes (copy paste problem)? My main concern though is that non injective file to module mapping may complicate the implementation of some rust tools. Here is another hypothetical example of this. Suppose you implement incremental compilation for rustc. You will need a mapping from files to modules. If mod aliasing is alowed, then you will need a multimapping. So you end up with more complex code which is used only in a tiny fraction of projects and because of this probably contains some bugs.
Ah, I see. So it seems to me that the problem is that should not be allowed in contexts where would be illegal. In other words, an inline module should only be considered a "directory owner" if it is located within a directory owner. A compromise might be Yet Another Lint Warning. ;) I agree with you about preventing people from shooting themselves in the leg, but I guess I think people don't use lightly or frequently, so this seems unlikely to be a major source of confusion.
I totally agree that this curiosity is insignificant for users. But I still worry more about the implementation side of the issue, and a lint warning does not help here.


This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim


These are configured something like
I am not sure why this happens off hand, but when bootstrapping the non-build-triple compilers artifacts are copied from e.g. to .


The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.


With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?


Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc


root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.


Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by


I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim


Basically just change this macro to recognize and discard the trailing comma.
That macro declaration is formatted in a weird way. But anyway it should be enough to add to the rule (unless accepting multiple trailing commas is undesired). I could mentor.
How about this:
Out of curiosity, why doesn't rust allow trailing commas after automatically? Does it make it hard to write some macros? Alternately, why isn't there a (optional) repetition specification (e.g. would be 0 or 1 times)?
The extra rule is fine too. It's just more annoying (extra repetition). And there's no technical reason not to support one-or-none patterns as far as I'm aware.
Made a PR :)


<!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:


The error happens on latest stable and nightly. Steps to reproduce: ; : : returns error: The error only happens if the module is named (for instance, and work without error). The error is not produced if doesn't use in any way. If doesn't contain imports but uses the library directly (e.g. ), the error is produced. always succeeds. I don't know if this is supposed to be forbidden but the error message seems to be misleading.
The second instance is injected implicitly. The error could be better, yes.
Where exactly is injected - in the library or in the test? Why does the library work on its own? Why does conflict with in the test?
Ok, it turns out this is a legitimate bug, I misinterpreted it as a more commonly reported diagnostic issue. is injected into both the library and the test, but only the first one causes the error. If you set in , then you'll see the error immediately while compiling - conflicts with . On 2018 edition, however, is injected in more subtle way, as where is some unique symbol that still has the string representation , but doesn't clash with anything in the same crate. Unfortunately, turns into "just " after encoding into metadata in the compiled library (this is the bug). So, when we load that library from the test it looks like the library defines two conflicting items.
The solution is to either encode gensyms/hygiene into metadata properly (this is a large task and a long standing issue), or come up with some hack preventing the injected specifically from being encoded (it doesn't really need to be encoded).
Fixed in


In a recent PR I made a change to unify the wording of multiple privacy errors, but : used to be This one change needs to be reversed while keeping the rest.
Hi! Could I give this issue a shot?
I am sorry I forgot to claim the issue
No worries :-)


was closed when stabilized the corresponding language feature, but we didn’t realize that it was also the tracking issue for this standard library feature: History: [x] Original tracking issue: [x] Discussion of payload vs message [x] Making .message() infallible: [x] Split core/std PanicInfo into two types: This made core::panic::PanicInfo::message() infallible. [x] Use opaque return type: [x] FCP [x] Stablization PR: Unresolved questions: [x] Should it be infallible? Yes, by making std::panic::PanicHookInfo a different type. [x] What should the return type be? or an opaque ? The first is simpler, but the latter allows a bit more flexibility for future changes.
Instead of making a PR go through the queue to fix the tracking issue, should we stabilize this method? fcp merge The doc-comment is slightly wrong or out of date. Its second line shoudl be removed. always creates a where is , regardless of the number of arguments given. In the single-argument case, that argument is required to have type . At first returning seemed unusual to me and I considered that we could make the method return instead, on the basis that calling its impl is almost the only useful thing to do with a . But has been stable and documented as the return type of since 1.0.0, so maybe it’s fine.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [ ] [x] [x] [ ] [ ] [ ] Concerns: single-arg core::panic () 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.
The module also links to that closed tracking issue. Let’s consider the pFCP above to also include stabilizing it. ( is stable.)
concern single-arg core::panic Should we change libcore’s macro so that its single-argument form creates a with a instead of one with a ?


CC Pushing this idea further, it’s tempting to maybe remove entirely and instead have a whose dynamic type can be . But that doesn’t work because is a method of and is not .
I thought the point of the message field was that core can't make a payload since it can't allocate?
The struct is: Both the and fields involve borrowing. As far as is concerned, they could both be borrowing form a stack frame. (And as far as I understand they are, in practice today.) It’s in the case of unwinding that there’s an owned that can return, which requires allocating.
Based on the timing of it looks like you may have thoughts on this :)
Ah, goes into how and why the panic handler in libstd (which is called by if libstd is linked) ignores the it receives. We could probably change this but it gets tricky: while most implementations of for environments would be fine with receiving a borrowed payload, libstd wants to potentially take ownership and box it for unwinding.
I have zero recollection for why this is the way it is, and I'm not really particularly interested in doing all the archaeology to dig up why it is the way it is. I'm not a huge fan of just stabilizing things because they happen to be there, but I don't really see why we wouldn't want to stabilize this. If there were a reason to not stabilize this though an investigation would presumably turn that up, but I'm not up to do that investigation myself.
That’s totally fair. I’m confident that this was more likely forgotten than deliberately left unstable. If deliberate we would have kept the tracking issue open or made a new one for the remaining bits. This is what lead me to propose stabilization. Having dug a little more, and thanks to Ralf’s blog post, I think we may want at some point to revisit what data we expect to contain or not in various situation. In particular it could be interesting to extend to support payloads other than and make it closer to . Given those possibly-desirable changes, it may not be the time to add more constraints: fcp cancel
proposal cancelled.
Lol, I had no idea. ;) So, indeed, I was wondering if we could do something about the duality of the and fields in . I assume we cannot change the fact that the same type is used both of panic handlers and panic hooks.


Concretely, I was thinking of adjusting somewhat like this: That would at least remove the need for the hack in . (The hack would likely move to instead, but that is a smaller hack IMO: the hack is now not encoded in the state of any more, just in its dynamic API.) I think this would retain all current functionality while clarifying the invariant of wrt. the payload (and explicitly calling the message a "payload"; right now it seems to be something that sits next to the payload which is inaccruate). But there are enough subtleties here that we'll only really know once someone implements this. With this change, the panic hook would always get a . We should likely provide a method somewhere in libstd to factor out this code: I was imagining something like an extension trait on with a type like . However, the panic hook is not the only place where that conversion is useful; another situation is code that caught a panic and wants to extract the message. I expect most instances of that to just handle payloads, not knowing that payloads are also common (that is certainly what happened when I wrote such code). So ideally we'd have a method that takes and returns , but I do not have a good idea where to put that. This is the hard part, as we cannot use . I wonder if we can use a take-based approach, similar to ? Conceptually, would put the panic into an , and somehow pass an to the panic handler, and the implementation of said handler could then the payload if it needs full ownership (like for unwinding). Except the panic handler cannot be generic, so it would have to be , which is not a thing. But with enough unsafe code we could re-implement something that behaves like that. I don't see any way to do this entirely safely; the panic handler that wants to take out the payload and put it somewhere needs to dynamically determine the size of the payload and arrange for there to be enough space. In liballoc, we could provide a safe wrapper for this that puts things into a , but in libcore, I don't think there is a safe API that we could provide to grab ownership.


But maybe it is enough for the public API to expose ways to borrow the payload (should work for all non-unwinding handlers); if only libstd needs to take the payload (for unwinding) we could keep the unsafe part of the API internal. Also, we certainly do not want a panic hook to the payload out of its . At this point it seems to be quite a problem that panic hook and panic handler both use the same type. In fact, a panic handler likely wants a to be able to things without interior mutability. Is there any way we could make the attribute support both signatures, and then (based on the types of the methods) only -based implementations will actually be able to or the payload?
I agree, but it’s can easily be an inherent method of nor of because those are in libcore which doesn’t have access to . It feels slightly unfortunate that we’d need an extension trait just for this. I considered this yesterday and come to pretty much the same conclusions. To take ownership of a payload of unknown size through a non-generic API we pretty much heap allocation, which for libcore means something like receiving an , unsafely using , and returning that is to be passed to . It’s not pretty, but if only libcore and libstd deal with this internally maybe that’s ok? Is there a use case for a other than libstd’s to take ownership of the payload?
I was thinking of a slightly different API actually: Here, does to put the payload into caller-allocated storage; that storage must have (at least) size and align as given by . What I did not consider is how to get out the vtable, so maybe that higher-order approach is better.
We discussed this in the libs-api meeting today. We concluded that before stabilizing this, we need to make sure it works (doesn't return ) for std::panic!() as well. That is already the case with Rust 2021's std::panic!() (since it's identical to core::panic!() in this edition), but not for Rust 2015/2018's std::panic!(). Once that is fixed, we feel okay with returning a placeholder message for non-string panics (panics from or Rust 2015/2018's ), at which point the function can return an unconditionally, rather than an .


(And also, should be returned by value, not by reference.)
Any progress on stabilization?
It would great to have this little feature.
Still nothing? What's missing?
can this be stabilized after was resolved in the pull request ?
Yes, soon, hopefully! I've updated the overview at the top of this tracking issue. The main question left before stabilization is the return type of the method. Should this return (as the unstable method does today), or should it return an opaque type that wraps that fmt::Arguments, so we can still change in the future? (In case we want to support different types of no_std panic, such as panicking with an Error or something.)
Can it return or so?
I would vote for an opaque type that would also implement .
Did that in this PR:
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [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. This will be merged soon.


File: snippet: 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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be:


On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim


According to , the standalone tarball installer of stable Rust releases includes Miri. That's a bug, Miri is a nightly-only tool and should not be shipped on stable. Cc
Posted a fix at .


Happens on WIndows 7 x64 with latest Rust 32-bit nightly. : (On a side note, is there any way to work out what the latest released nightly version is?) : Compiling with produces: is there to suppress the warning, can be removed if you compile the rest as a library. Also works if you substitute the expression for directly and if you pass two arguments (the original use case). The original intent was to tell if two s were identical as a sanity check.
Can confirm this still results in an ICE.
Triage: still ICEs.
cc rust-lang/rfcs
fixed this.
I'll add a regression test for this


<details<summaryBacktrace</summary</detailsWindows 10 (64-bit)
Which code had caused this assertion? Caused by this assertion: Which was introduced in , which is beta-nominated. cc
I'm glad I that assertion! What it likely means is that isn't a multiple of . I'd be quite surprised if and/or weren't involved.
In my case this error is caused by the crate. Simply including it in your and compiling crashes rustc. <details<summaryBacktrace</summary</detailsI'm on Arch running the latest nightly rustc.
Looks like triggers the assertion, and it has alignment but size (which is illegal), IIRC, includes some types that are ( this is indeed which has a packed ) and has caused issues in the past as well. EDIT: minimal repro:


When setting the directory to persist doctests to if an UNC path is used on windows there's a segfault. The offending setting of persist-doctests: . cargo-tarpaulin sets this programatically using a path it gets for the target directory from cargo-metadata. The path from cargo-metadata is an UNC path and this then causes a segfault. I'm going to detect UNC paths in my code and remove the on windows, but I felt this warrants a bug report as someone else will hit it eventually. Also, I'm not sure if other parts of the compiler fall prey to this issue? Compiler version is: the latest nightly (1.64.0-nightly 2022-06-28) The stack trace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This panic is also triggered in Linux if e.g. trying to write into a directory that the user has no permission to write. I PR'd fix to change the unwrap to more orderly panic and relaying the underlying error detail via eprintln! ~/gg/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc --test -Z unstable-options --persist-doctests /tmp/foobar Couldn't create directory for doctest executables: Permission denied (os error 13) instead of:
The lack of ICE is definitely nicer, but this still won't handle UNC paths on windows will it? Which is the main issue I personally have with the code
That's a problem for std::fs::createdirall(&path) me thinks has to be fixed there
Makes sense looking at the code, should I raise another issue for the libs team?
Actually, yes it would be great to raise another issue targeting std::fs::createdirall - as it is wider issue. you are right. Thanks!
So isn't this an issue with the tool generating an incorrect argument?
So the paths are weirding me out (I normally only use linux), because they seem to sometimes print differently given different display methods. It shows up as printing the path in my rust code before making the env var, and if I print the rustdocflags I'm setting it's correct.


But if I do it returns false, I have to do for it to return true. I'll raise the other issue and after work look into it more properly try to make a better MRE for windows
do you mind changing title s/UNC/invalid/ to address the panic on this issue, thanks! :)
also please remove s/on windows// thanks a lot :+1:
Done, and I realised what was wrong with the path, it's correct in the code, it's just when it got set into the environment variable it seems it needed the first slash to be escaped and that caused the invalid path (so no issues in std::fs need fixing)
claim label +I-ICE +T-RUSTDOC


STR (on Linux): file that has generics usage () code DWARF info Notice that contains such entries as , possibly produced by the fact that "" is a relative path and DWATcompdir is set to "/home/yury". It is expected for core files to have absolute path e.g. ""
cc I wonder what interaction (path rewriting?) causes this result.
FWIW, produces that shows that !DIFile entries has the directory field empty (and the filename is relative)
It is a regression, since +stable has absolute locations, e.g.
could this have to do with
Likely so! I'll try to look into this in the near future
Ok so the change here can be exhibited with this script: If you execute that script you see: but if you remove you see: It appears that if upstream crates (like libstd) use then their filename is listed as the original relative source file instead of the absolute path name that it had previous to when it wasn't compiled with . So somehow using to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping. would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!
This should be what you're looking for: One solution would be to compile libstd with absolute paths and apply proper remapping to those.
Ah that's perfect! I'll see if I can work up a solution to that soon


<!-- 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. --(reduced) (original) <!-- 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 --
Please try to minimize the example as much as possible:
claim
heads up that already put up a fix
Thanks Just want to add that some other intrinsics also ICE. For example: ICEs as well.
Interesting -- I wonder if we should perhaps fix this in a less specific way than . I wonder if we should instead detect that the declaration is not valid b/c has not been enabled in the crate... If not, then I'd be glad to review a PR that fixes whatever other intrinsics you find to make too many assumptions in the compiler.
Even adding does not prevent the ICE unfortunately. It happens in due to the wrong number of arguments e.g. here for : occurs for a lot of intrinsics in this file. I'm guessing all of them will ICE under the conditions in this issue. To fix it, we could extend what's done for in to all intrinsics, maybe leveraging this code to know how many args are expected for any given intrinsic:
I have opened
Looks like intrinsics are expected to ICE if used wrongly (see comment: ) so I opened has been rightly closed. But that mean that should also ICE in these conditions. However, in the present issue it was ICEing for the wrong reason i.e. out of bound access . So does the right thing by stopping that. However, IMHO it should not taint the context and let it go to MIR lowering and then let it ICE there. That keeps consistent with other intrinsics' behaviour as noted above. Thoughts & If you guys agree I can open a PR to remove the tainting.
See which takes a different approach
Nice!


When encountering a , there must be a corresponding in the MIR body. If there isn't, later passes can panic due to indexing out of bounds of the array. The validation pass could detect this problem earlier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Instructions: Extend the validation pass in by implementing for the MIR visitor: The trait is documented . The method should check that the local exists in , and fail with a descriptive error message if not (by calling , not by panicking directly).
claim
FYI, the validation pass currently fails on even libcore until is merged, so you need to either wait for that, or cherry-pick some commits from there to get it to work. You can test your changes by running (the validator only runs on very little code by default, turns it on for everything).
I wanted to double check, running should fail when I run it, right? It actually passed for me after I merged in your branch from I wonder if I should try clean and build stage 1 again. :
It should pass with applied, but fail on current master.
So your PR fixes this issue () as well?
Ah, no, this issue is just about adding additional validation. It shouldn't actually detect any locals that don't exist. So the command should work both before and after implementing this. If it fails after implementing this, something else is going on that we should look into.
are you still working on this?
No, sorry. Didn’t have time for it. Go ahead.
release-assignment
Would like to work on this, but it seems there is another check, not on the declaration like this one, but on the memory liveness. This should cover the case that the local is not declared (I think), or would it not?


This is intended to be a tracking issue to incorporate into the current beta branch for the Rust 2018 release, as we'll be relying on that in documentation that we're writing.
The Cargo backport is happening here - , and after that needs a PR to the beta branch in this repository
This is now submitted as
Done!


<!-- 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: /// let example = Example::new() /// .first("hello") #[cfgattr(not(feature = "one"), doc = " .second("hello")n")] /// .third("hello") /// .build(); /// with I expected to see this: ! 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. --: running over the code gives me /// let example = Example::new() /// .first("hello") /// .second("hello") /// .third("hello") /// .build(); ///
As explained on discord, <strikethe attributes aren't applied to doc comments</strike(EDIT: they are applied, the problem seems to be that it results in two doc comments for rustdoc). However, your doc comment is split in two so the second half isn't considered as being inside a code block, explaining why you have this display. Even if shows it as one doc comment, rustdoc sees two of them. <strikeMaybe we should add a warning or something that attributes aren't applied to doc comments... What do you think ?</strike
How can an attribute get applied to a doc comment? Both are, under the hood, attributes, no? I would expect that to be equivalent to expecting to only derive Debug if is passed, which is not how that works. I'm guessing what is true is that attributes directly written don't actually merge with -style comments. Potentially relevant: , ,
Simplified reproducer rust //! foo(); #![doc = " bar();"] //! Checking with 1.31.0 it still ignores it (so likely not related), but checking with 1.21.0 (and 1.0.0) it worked as expected, so somewhere within that range (but I don't have any other versions installed at the moment to check).
Compilation broke somewhere between 1.23.0 (works) 1.24.0 (does not work) I tested it with rust //! let x = r#" #![doc = " bar();"] //! "#; //! assert_eq!


(x, "n bar();n"); //!
They are not supposed to be applied to a doc comment I do not think that. Your example would make sense for which I also consider to be wrong, but I am talking about which should insert the attribute conditionally but that is not the point. It might help to illustrate my thought process; We have some kind of documented item: rust /// let example = Example::new() /// .first() /// .build(); /// and each of those is turned into a doc attribute rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " In a later step those attributes would then be concatenated and parsed as markdown or whatever. I want to use this behavior to document items conditionally, depending on which features the crate user has enabled. One way to do this would be to do rust let example = Example::new() .first() .build(); rust let example = Example::new() .first() .second() .build(); but that would blow up the source code with many duplicate lines, where only some minor things were changed. So I thought that it might make more sense to conditionally include a doc comment like this: rust /// let example = Example::new() /// .first() #[cfgattr(feature = "one", doc = " .second()")] /// .build(); /// which would turn into rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .second()"] #[doc = " .build();"] #[doc = " or rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[doc = " .build();"] #[doc = " depending on whether the feature is enabled. So the attribute should not be inserted and not applied to the following doc comment. The weird thing is that the manually expanded version is working as expected. rust"] #[doc = "let example = Example::new()"] #[doc = " .first()"] #[cfg_attr(feature = "one", doc = " .second()")] #[doc = " .build();"] #[doc = " but this is very unhandy to work with :/
I was randomly looking at passes for another reason and noticed what is likely the source of this issue.


There are two relevant passes: runs second and removes leading columns of whitespace from the docs. This runs on a single "doc fragment" at a time, because of merging that normally means the entire documentation string, but since sugared and raw docs aren't merged they remain as separate fragments and use their own widths of leading whitespace to strip.
That also matches up with first released in 1.24 which introduced this distinction between doc kinds in order to fix , which IMO was user error in not matching the indent depth.


The idea of shortening to has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing to , we instead just make expand into when in the context of a variable declaration. For example: This solves the problems (readability, more concise) that people have with , whilst not causing the issues that people have (pattern matching and consistancy). The most common issue people have with aliasing to is that it doesn't fit well with patterns, like . However, gets rid of this problem, because you wouldn't write if you were trying to pattern match, so why would someone want to write ? You wouldn't do that, and it wouldn't compile. This would be optional, of course. would still work fine, and people would just have to option of removing the to let it be implied. There are a lot of other abbreviations used in rust (, , ) that all serve the purpose of writing less. It just doesn't feel right that one of the most commonly used keywords is so long. :heart::crab: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rust wants to make to make you think when you try and use mutation, even if only a little bit, because mutation can be difficult to reason about. Shortening to doesn't fit this philosophy. Also, this makes mutation just as easy as no mutation. This will lead people to choose mutation because it will give them less compiler errors in the short term, and in doing so open themselves up to some weird bugs that could have been prevented with the syntactic salt that is . tldr: wasn't rejected because of the name , but because it allowed easy mutation, which runs counter to Rust's philosophy.
I politely disagree. In fact, it is actually the other way around. Using unnecessarily will cause compiler warnings, discouraging the use of unneeded mutability. The compiler doesn't warn when the use of is actually needed.
The fact that people will choose in the face of compiler warnings has been shown in practice, across many projects.


Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.


Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)


From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.


I tried on Rust 1.76.0: I got the following error: Note that the suggestion has stripped the leading character from the enum's name.
Can confirm this is still present in nightly.
Sounds like fun. Taking a look.
So it is intended this way from what I can see in the source code: Improving the wording would be become to clear the confusion though I think.


I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.


When running , this file is opened for me . I thought I'd use that file in my note taking application, which I have set to a dark theme. However for in that documentation is set to have the and the background uses the default color. This leads to the text becoming hard to read. ! I would prefer the text color not to be explicitly set, or if you insist on the dark gray text, making sure that the background color is also set to something light.
Transferred to rust-lang/rust. The CSS for this lives at
It's not rustdoc so to speak. I'll fix the issue.


<!-- 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. --: This bug was also reproduced in the stable version(1.72) <!-- 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
Hmm this was caused by cc
claim


The following code will fail to compile at "Self::new()" with the message, "error: failed to resolve. Use of undeclared type or module " While either of the following will work: The first example should compile as-is.


is a keyword, this error message indicates that it can be used to define type, which is misleading.
There is a similar issue: file.
No, that's a different issue. At the time that issue was filed, was not a keyword, just a confusing type. That said, at the time that issue was reported, it's fine to say the compiler was implemented properly. But my issue is about wrong error message, not bad(confusing) error message.
Do you mean is not a special ident now? I found the example code can be compiled, and there is excluding self type code
My point is that we are in different situation now. See and notice that it happened after the time the issue we discuss was filed.
Actually, IIRC we're moving towards a direction where can be used everywhere in a trait or impl context. I'm not sure though. any idea?
Yes we can use it in traits or impls. is totally legal for instance. But inside global functions can not be explained if I understand correctly.
Oh, sorry, this was a global fn. Makes sense.


Consider this code: The error is: It'd be nice if the explicit ref wasn't required in this case.
cc
This has now been fixed.
I believe this is covered by


A documentation comment like the one cited verbatim below, produces a main page summary that includes the first line of the code in the example. This is very surprising since there's an empty line in between, and the code example inserts a large colored box in the overview page (the parent module). cc since it's probably related to PR /// A tuple or fixed size array that can be used to index an array. /// /// /// /// Note the blanket implementation that's not visible in rustdoc: /// !


I will like to fix this. What should be the better warning message here? Or I just need to remove the last sentence?
It seems fine to just remove the sentence.
Fixed by


This is while debug printing all mir statements of libcore.
modify labels: +A-mir +C-bug +requires-nightly
This also reproduces on .
The incorrectly assumes at several places that the allocation kind is always what the type should contain. It for example assumes that an value always points to a function, and always points to raw bytes. It also ignores relocations at several places.
Triage: I think this ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.


Minimal reproducer: Make sure to run rustc with to reproduce! Using doesn't fix this.
Minimal repro:
Other failure with code causing the above problem: This one is observable by printing the whole mir using , unlike the other, which requires you to debug print every statement.
cc
That second one is a miri assertion: Interestingly, there's an afterwards that would be more helpful if it were before: cc
It seems like no longer ICE with latest nightly, I guess fixed this (CC: Marked as E-needstest
points out hasn't been fixed yet, dropping E-needstest.
Is the issue description still accurate? "Can't debug format a mir stmt in DefId" reminds me of a after we had some ICE issues with debug-printing DefIds. But as far as I can see, no example mentioned here even triggers an ICE with that message. The ICEs described here sound very different than that, they look like CTFE is not handling ZSTs properly somewhere.
I cannot on beta or nightly, so it looks pretty fixed to me. can you still reproduce this issue with latest nightly? The first backtrace has no code, so it is impossible to debug; the second backtrace (the one with self-contained code) does not seem to ICE any more.
Uhm? I don't think so, did you run with ?
Ah, I just ran on playground. It would be good to have up-to-date reproduction instructions in the first post, and not just in the third post below a huge stacktrace.
Yeah, but I don't have write access :/
Ouch, sorry. :( I didn't know. I will update the OP.
<details<summaryHere's a backtrace with debug info</summary</details Looks like the is wrong.
Triage: I think that ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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!
Sure, I can look at this one.
Thanks for merging ! If I'm reading things right, I think I need a new crater release of it so I can update ? If so, can you please make one of those?


` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign


Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Const generic defaults are being stabilized, <!-- 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 --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ?


Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta


Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?


I need to give a Rust slice to a C API that will return an opaque handle (that actually contains a pointer to the slice), and the slice must outlive the handle. nicely suggested using for this, but the description of phantom data (and its RFC) for me is so far removed from my mental model/terminology of the problem, that it . "…tell the compiler about fake fields" — fake field doesn't sound like a thing I want to create. I'm not sure if a fake field is an actual Rust concept. I'm hoping it's a different way of saying a "pointer that Rust isn't keeping track of". "inform the compiler that one or more instances of the type T could be dropped" — but does it actually drop anything? I want to prevent value from being dropped, so this confuses me. The RFC is even worse, since it uses type variance terminology which is so confusing, that the most comprehensible description of them on Wikipedia is a 3D cube! !
allows you to describe that a type acts as if it stores a value of type , e.g. maybe one is having to use opaque pointers or otherwise disguise the fact that there is a contained in the value, or need to have a lifetime without having an actual reference to attach it to. This is what is meant by "fake field": a field doesn't actually store any data, but it behaves as if it does. If you have a lifetime, and the type is acting like a reference, then (or ) is the recommended approach. It's hard to be more specific without knowing your exact use-case, though. In any case, the major motivation for is to avoiding having to think in terms of co*variance, and instead just think of what the intended "storage" of a type is. The RFC is meant to serve as a technical reference to describe the behaviour unambiguously. I definitely agree that the current docs are not as helpful as they could be.
I see you've used lifetime as part of 's type. In my code I've used and got confusing error messages. That bit in the documentation would help a lot! (just saying is very unhelpful) BTW: the first paragraph in your comment is already clearer to me than the documentation :)
The example seems relevant.


A previous example was referenced at the though I think rustbyexample is clearer. Note that the syntax of this example has changed recently. That didn't used to be required. If indeed what you need is something similar, you should flag it on rustbyexample for a more practical example. I was only aware of using phantom types in for use cases like unit system manipulation and such. If you can provide the gist of what other things they can be used for I can probably shoehorn it into an rustbyexample example(s) (there's IRC if I get stuck). Though I don't know when I'd get to it.
is designed as a low-level building block to enable certain types of unsafe code to be written safely. The relationship to phantom types (as used for dimensional analysis etc.) is the name (almost-coincidence) and the fact that the language doesn't allow type parameters to be left completely unused (meaning a phantom type has to be mentioned, e.g, in , to let the code compile). Almost instances of phantom types for dimensional analysis won't care about the precise variance (unlike unsafe/low-level code) and so just need to make the compiler shut up. :)
great that you've made progress!
Okay. The distinction between them is definitely unclear then too (in the docs).
If it's just to make the compiler shut up, then it's a good indication that the old default was better (not needing PhantomData for most unused type parameters).
I sympathize. PhantomData and PhantomFn are Byzantine to me as well, and I'm hitting several issues in rlibc because of them.
, because unused parameter did absolutely nothing, even when I used a parameter with the same name a method. I don't mind having a marker, I just needed to learn how to use it.
To be clear, it is just the use of 'unused' type parameters for dimensional analysis/tagging where the details of the precise used aren't so important. It is extremely important for data structures building on (or otherwise not using their lifetime/type parameters directly internally) to get their uses correct, as they are actually informing the compiler of information necessary for safety. There has been a regular stream of bugs/problems discovered in types in this repo due to the old default not helping with code.


(I imagine that many external libs with data structures have had to insert 's since the change... meaning they were likely incorrect too.)


Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Where can I learn more about how this check is done? I just built stage 1 compiler with current master, and I was able to build miri with .
I'm guessing one of the tests is failing because it now needs a . The failure should be hidden somewhere in the logs of the runner:
should fix tihs.
Ah, so the problem is in one of the tests.. I only checked building.
usually, should let you run the tests, but this is currently broken by


It shows up on and , but not on or
This is actually a known bug in rustdoc and/or the compiler, although I can't seem to find the issue right now... Basically it'll suffice to just tag the trait with for now.


This code will fail to link because is merged into . Since global asms in LLVM can't reference symbols natively, we currently will add the mangled name to the string and pass it to LLVM. To prevent the file being optimized away, we add it to . A few issues exist: does not handle these functions specially, and therefore above is considered as internal function and have attribute attached. LLVM believes that it is allowed to merge internal functions into an exported function despite present in . I think LLVM should be allowed to this because we emit the internal linkage, and from my understanding renaming a local symbol should probably be allowed. argues otherwise and says that shouldn't touch the symbol. The symbols are , but it wouldn't show up as used in the exported symbol list, so it can still be stripped while doing LTO. We should do the following: [ ] Ensure that these functions are not emitted with internal linkage [ ] Ensrue that the functions used will be marked as used in and thus reach the linker/LTO. [ ] Ask LLVM to clarify the behaviour of combining + . cc label: +A-inline-assembly +F-asm This will block
I think should be enough to ensure that the symbol reaches the linker even through LTO. So really the only thing to do is change the symbol visibility. This isn't ideal though since we don't need this symbol to be exported outside the current compilation unit, it's just that LLVM is unable to see the use of the symbol.
It could be argued that this is actually an LLVM bug since linkage is supposed to preserve the symbol name in the object file:
I had to have to prevent from being thrown away.
Anyway, the biggest issue is the linkage, which is wrong anyway if the global asm and the referenced symbol are not in the same CGU. Given that currently both and the linkage computation comes from the same source of truth , a potential fix should be able to address all issues simultaneously.
This is fixed by . The proper behavior for LLVM is still unclear, but at least fixes the immediate issue since those symbols now have external linkage. This is a separate issue, but I think the proper way to fix this is to ensure that the itself reaches the linker. The problem here is that if there are no symbols to pull in the object file containing a from an archive then that will not be linked into the final binary.


I think we can fix this by inserting a dummy symbol in the and then including that symbol in the synthetic object file from .
It's of a different cause, but will have the same effect. I prefer to have it tracked in the same issue (but different work items). The problem is two fold. For the normal non-LTO linking, what you described is sufficient. The major issue is LTO. Because LTO works on IR but not binary, it doesn't know if a symbol is being used in . We need to pass a list of symbols to LLVM to ensure they are kept. Currently this includes all exported and symbols, but it also needs to include all symbols referenced by .
Do you have an example demonstrating the LTO related issue? Optimizations during LTO cannot remove symbols from yet, since as you describe the references to those symbols from the inline assembly are still opaque to it. For example, the internalize pass in LLVM comments:
That comment suggests that even with internal visibility, LLVM isn't supposed to delete a symbol that is used by . So perhaps the issue really is in the MergeFunctions pass which should be fixed to preserve a symbol alias if that symbol is used by .
Here's my attempt at a fix in LLVM, but I'm not too happy about the code. It could use some review by someone more familiar with LLVM.


Ran into this when running a fauly tt muncher with ~100 items. We can now compete with C++ in the compiler spew area as well! :-P
Ran into this while demonstrating why you need raw pointers to do a singly-linked-queue: 66 Borrow check errors in this test.


The following code snippet demonstrating or-patterns crashes the nightly compiler on the Playground as of 2-2-2020. () I understand that or-patterns are incomplete feature, thus errors are expected. But I was told to anyway (cc: It's not convenient for me to test locally right now; is it possible to get a backtrace on the Playground?
You might want to throw this into your PR () as a test case.
Would appreciate clarification here: I don't believe pattern binding with or-patterns within function arguments () is semantically different from a pattern consisting of only the variable name (). However, it's semantically valid code, and can be used as a contrived example to demonstrate exhaustive pattern matching. Which is how I found this ICE in the first place.
It's semantically equivalent, but it results in different code-paths in the compiler. I'm quite sure that will fix this though as it seems more or less like a dupe of (but different enough that a test case should maybe be ). The MIR parts of or-patterns have simply not been implemented yet, but we're pretty close.


<!-- 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: <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It doesn't seem to be related to GAT, only influenced by TAIT.
seems like another version of
claim


Updated to via rustup. I have a and additional which specify additional rustc arguments. Now if I run The build will succeed but then fail to run qemu because Instead, there's a file named in the directory where xargo was run from. To fix this I had to change the target json file with these options: I'm afraid this could subtly break my builds elsewhere, as the linker is, in fact, GNU ld. I believe this is related to the latest -pie/-no-pie patches which somehow interfere with custom cargo linker arguments specifications (where ends up landing instead of output file name).
Seems like is likely to be related?
That's my suspicion
hmm my change shouldn't have impacted when the -pie flag was sent, only the -no-pie flag. what version were you using before?
Could you please build with and post the output related to the link step (after the line)
triage: P-high Not assigning this to anyone immediately, since seems to be on it -- if you could take a shot at supplying that debug output it would be very helpful, thanks. =)
does that contain the info you needed?
It does look weird as I don't see any standalone in the command line.
Yes, that helps. I think this is what is happening: Even though you have set in your target file to produce position-independent-executables (pass the "-pie" flag), the code overrides this because it sees "-static" on the linker's command line and decides not to generate PIE. My PR made it pass "-no-pie" in this case, and fall back to removing -no-pie if the link fails For some reason this seems to be confusing ld instead of causing it to generate an error Can you confirm this by manually running: (same command line without -no-pie) to see if it works correctly, and also a ? I need to look more into ld to see if -no-pie is even necessary for it, I think maybe the default pie stuff might only be applicable with the gcc front-end. If so, I think the fix would be to change the code not to generate -no-pie if linking with ld.
nm, I think I was able to reproduce this. I don't see -no-pie documented for ld so I think that is the problem. I'll work on a fix.
Thanks, I will test this asap!
Works! Thank you!


As noted in which tracks the diagnostic issue, the standard library previously accepted code (with differing behavior) on a number of intrinsics with "intended to be const" arguments. Since , though, this code is rejected at compile-time. For example, this compiles on stable but not 1.54 (nightly as of this writing). I think at minimum we need to identify the set of code that changed behaviors and document that in release notes.
cc -- on the point about documenting this change in behavior in the release notes, would you be up for either identifying the set of intrinsics which changed behavior or documenting how to do so?
Looking back at the crater run, we only ran it in mode, which doesn't perform monomorphization. This is the reason why this wasn't caught earlier. The full crater run for beta is currently running, so we should be able to get a clearer picture of the breakage once it is done. Documenting this is difficult: the new behavior affects all intrinsics which use const arguments. A quick grep of stdarch shows 1741 intrinsics, of which about ~150 are stable.
This is in 1.54, not 1.53, so the currently running beta run won't catch anything, right? It may make sense to run a crater on the PR itself, though. It is worrying that so many intrinsics are affected towards a compile-error, vs. e.g. having a warning - perhaps deny-by-default - like clippy's on the atomic Ordering params...
run mode=build-only end= start= name=issue-
:okhand: Experiment created and queued. :mag: You can check out and . :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
The mechanism used to validate the immediates using const generics is: offering the validation feature: a post-monomorphization error while evaluating a forcing the evaluation of the const for the const generic parameters of a given intrinsic: e.g. the above is as and the body of the intrinsic will start with a static assertion ensuring is indeed a 4-bit value. Note that I've linked to the more common macros, but this mechanism is applied throughout including arch-specific intrinsics and validations: e.g. , or .