In <https://rust- identified the root cause of (unnecessary stage 1 cargo rebuilds) being The other instance of this is As (thank you so much) pointed out: I tried to limit application of to and binary wrappers in themselves, and unfortunately this leads to two cargo test failures: <details<summaryPrevious history</summaryI'm putting up a PR () to remove conditionally adding , and as we expect two cargo tests to be broken with if that is unconditionally passed to bootstrap. I don't know if this breaks someone's workflow regarding to piping cargo tool tests, but in the interest of not making everyone rebuild stage1 cargo on every single invocation of , I'm considering this as "known breakage" for the time being. As suggested: </details
cc team in case anyone has any advice regarding these two tests.
cc if you have any advice since this was in for (it didn't occur to me that adding would cause build cache invalidation problems), presumably to workaround the cargo test failures.
Thanks for the ping. Unfortunately I currently do not have the time to look into this.
No worries that is fine, pinged just in case you had immediate context or advice.
Maybe we should only run those two tests in rust-lang/cargo CI?
Can you give some more context? What are the benefits and drawbacks of ? What does that look like to the user of and ? I don't quite understand . It looks like it regresses something, but I'm not clear what. If it is breaking cargo tests, how is it possible for that PR to land? It seems like removing would be regressing whatever issue it was to fix in the first place, but I don't know what that is.
The linked PR does not break Cargo tests, it possibly breaks someone's contributor workflow that relies on bootstrap implicitly setting . Bootstrap can't implicitly set that flag for everything, or it breaks Cargo's tests. The bug here is that none of the numerous people who looked at the original PR (including me) noticed that the right thing to do here is not set the flag at all, because inconsistent flag-setting creates spurious rebuilds.
Yeah sorry I didn't know how to word the issue title accurately (please rename this issue if there's an more accurate description), will remove conditionally passed flags passed to cargo from bootstrap, which might break someone's workflow related to running cargo tool tests through bootstrap if they wanted to do something like (AFAICT) because now we don't pass at all, but unconditionally setting will cause the aforementioned test failures. EDIT: I tried to fixup the issue description and title to be more accurate.
Sorry, I'm still not clear what is being changed or what is being proposed. Also, sorry for many questions, but I don't have context on what is going on. What happens after when someone does ? What happened before? Is the concern after specifically about , or is it all bootstrap commands? Some of them? Does change the dist artifacts? If so, how? How much of this is specific to using versus using and ? Is there an original issue related to bootstrap workflows that initiated the introduction of ? Who is asking for a different behavior? Looking at , it seems like this stems back to . How does rustc now handle sigpipe? My naive thinking is that removing causes that to regress, but it doesn't seem like that is what you are proposing, and clearly no tests are being broken. But I don't see how all these pieces fit together.
only affects the entry point. Setting it on libraries is useless. I think could be used to add flags that only effect the final build and not any dependency.
... Actually thanks for asking these questions, it seems that simply removing these flags to fix rebuilds will regress rustc (and probably rustdoc) behavior with respect to broken pipes. rustc will ICE locally (e.g. , i.e. reintroduces ) without being built with that flag being set. The context is that I was trying to make not have to rebuild stage1 cargo even if nothing changed, because was not universally applied to tool builds (specifically excluding cargo), which causes tool build cache invalidation because stage1 cargo has to be rebuilt due to the differing flags. I will revert , investigate why regression test for rustc doesn't catch the broken pipe ICE, and reinvestigate what is going on with .
Apparently it does, I'm putting up a revert now. This unfortunately affects how itself is built. This was originally related to where we changed from the in-source attribute of UI to a command-line UI , so they were in an attempt to preserve the existing behavior of kill process if pipe is broken, instead of panicking (and possibly leading to an ICE for rustc specifically). Apparently through that flag when the main binary is being built. AFAICT your suspicions are correct, and indeed removing the flag will regress that. I don't know why no tests are being broken, which probably means no tests were actually exercising this behavior.
I tried to do some digging, and here's what I came up with. Note: the following investigation is to the best of my understanding and most likely contains inaccuracies and misleading representations, reader discretion is required In , the UI of changed to become an unstable rustc flag (cf. stabilization comment ). corresponds to . Not setting will default to . Note that this default behavior will lead to panic in Rust programs if the pipe is broken (e.g in a simple program ). For rustc binary it means the unexpected panic will be caught by the ICE handler manifesting in an ICE . For other tools like rustdoc or cargo it depends on how unexpected panics are handled, but nothing good. removed from rustc and rustdoc (i.e. from their binaries), and set to preserve kill-process-on-broken-pipe behavior to not have the panics and ICEs. Before was available, was addressed by adding a sigpipe handler in rustcdriver explicitly, as done in . But this was changed in for rustc and in for rustdoc to use which was intended to be a more reusable mechanism. Now removed attribute meaning that those flags are load-bearing, for building rustc and rustdoc binaries. Cargo might not be affected itself if it uses its own sigpipe handling, but I have not investigated that specifically.In to help with , we addedIn we moved being set only for tool build from to to help mitigate rebuilds for Miri tests (because setting only for rustdoc means if you build another tool, the tool build cache will get invalidated due to differing ). Note that this particular instance of is for tool builds and cargo, there is a different instance of for building the rustc binary itself in . Conditionally omitting for cargo itself does not cause tool build cache invalidation before (and ) because we were simply using bootstrap cargo (or rather, in bootstrap terms) and not try to build stage 1 cargo ourselves. Only tests want to build stage 1 cargo, even miri tests just use initial cargo. Now that tests builds stage 1 cargo, the omitted for cargo tool build specifically will lead to tool build cache invalidation due to differing . Note that I don't fully understand how tool build caches work and why differing for one of the tools can lead to tool build cache invalidation for all of the tools built from the same stage compiler.I tried to remove both instances of : The instance in : this I suspect was intended for binary. Now I think I understand I cannot remove this flag, because to at least binary I believe is load-bearing for kill-process-on-broken-pipe behavior due to UI changes to command-line flag as aforementioned. Not sure how cargo tests are affected, which is why the flag is not unconditionally always set in the first place. The instance in : this I definitely should not have removed because as I described previously is now load-bearing for the binary for kill-process-on-broken-pipe, otherwise it will reintroduce . I intend to revert now that I have a better understanding of why these flags are even there in the first place, and not having the flags set regresses broken-pipe behavior for and at the minimum. This effect includes dist builds of them so I practically introduced a P-critical regression to and if not also for other tools. I intend to try unconditionally set for all tool builds in so that (1) it preserves desired kill-process-on-broken-pipe behavior for and other tools that are typical of cli tools and (2) it should not cause tool build cache invalidation because it is not conditionally absent from cargo. I intend to investigate/fix a few things: Work with T-cargo and T-bootstrap to figure out why some cargo tests may fail on and either fix those tests and/or fix how cargo is building itself. Investigate why zero tests failed in full CI and locally, in both rustc and rustdoc test suites, even if I reintroduce the ICE for rustc and a similar panic for rustdoc. I intend to add regression tests for and for this behavior specifically, or fix the existing tests that didn't test what they intended to test.
I tried to update PR title and PR description to better reflect the current understanding regarding the two cargo test failures related to changing where is applied in bootstrap.


I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and


It seems that the prefix is used more often than , so we should swap the function names before 0.1.
We're probably going the other direction -
Done.


Yes, really
It looks like this is 2640 bytes of lovecraft quotes in each exectuable (out of , 0.56%). Perhaps it's not so bad?
2k is pretty bad, because a hello world binary should be ~10k at most. It's not the lowest hanging fruit right now but it will become a bigger fish as we fix the other problems. I think it's an indication of a larger issue rather than being a problem itself though...
I think there is no defensible reason to have that text in every executable.
And thus poetry was killed...
Not particularly new - and
2K? So that's what 2014 is about?
If you want Rust to be taken seriously as a systems language, you have to worry about that. It's not acceptable in many embedded environments for binaries to be this large. It makes the language unusable without writing the entire standard library again. It's fine for it to be in the standard libraries... just not every binary linking against them.
Should be fine until other sources of bloat are removed.
The problem here isn't the quotes, it's that the code containing the quotes is used or considered used at all. It's the canary in the coal mine. I'm sure we can cut down the runtime overhead to something much smaller, including getting rid of this.
It's not unreasonable for it to be considered used, considering it's part of the abort code, so even a trivial program might trigger it (e.g. on OOM, stack corruption, etc). Personally I'd add a no_horrors cfg option or something to disable it in the rare cases where 2k is considered important, unless the potential for user confusion is considered to great to keep the behaviour at all.
It's not rare for people to compare the size of the binaries to C and decide against using Rust for their use case due to it being very unfavourable. You shouldn't have to compile Rust again to disable debugging features useful only to the developers. This is only the runtime abort code, it's not the generic which isn't even a function call. Runtime errors should report real errors, and logic errors should be dealt with by improving the code so redundant checks aren't necessary in the normal release builds. It can remain around in a build that's not for regular end users... the code paths calling this just need some work to remove the need for debugging stuff.
Yeah but I love it though :( Hehe.
I also love it, but it's more important to be professional and chuck it out. Let's not make this Rust's equivalent to TPAAMAYIMNEKUDOTAYIM. Easter eggs are fun, but they have to have literally zero impact on users.
The key question isn't "is 2K big or small". The key question is "what value does this add".
Keeping these as default isn't very professional for many reasons, but I think value would be lost if lightheartedness was removed from Rust as a continuing policy. I've been amazed at how many people become interested in the language after I link them the abort in question. A human touch to the compiler output goes a long way. How about a '-fun' flag that enables easter eggs being compiled in?
Sounds a bit ridiculous tbh. The point of an easter egg is to have it everywhere, not to compile it purposefully.
Perhaps, but I'd argue the main point of an easter egg is to be entertainingly surprising. A flag enabling them wouldn't give away when they happen, just discourage unpleasant surprises. for a compiler. Another option would be to strip the messages when optimizations are enabled. -O equals -nofun.
That's funny, wordy and mawkish. "what value does this add"? Nothing. I'd vote +1 to remove them entirely.
Besides Lovecraft, I see tons of text obviously related to assertion failures and references to my build directory. I assume there is a lot of debugging code left in the compiler and libraries that will eventually get turned off in a production compiler, yes?
Am I the only one that's going to bring up copyright issues? I work for a company that thoroughly reviews code with lawyers that will ban any and all uses of software that are even questionable in terms of their license or copyright issues. You might claim embedding these quotes (and without attribution) is fair use etc, but all it takes is for one of my company's lawyers to disagree with your conclusion and suddenly Rust is banned from use in the company. I understand and appreciate the value of having some fun with a project, but these quotes: unnecessary overhead to executable size and memory (and yes, in real life I work on embedded systems where a few k can make a difference). potential users because a zealous lawyer has concerns regarding the quotes and bans Rust "just to be safe".
Lovecraft's works are basically public domain, it's not a problem.
To be fair, pretty sure copyright is the wrong case to make. Lovecraft's works are in the public domain. Edit: Dang, Steve beat me to it.
Won't the embedded environments you speak of use libcore?
True, but (but I probably should have been more specific because this issue specifically mention's Lovecraft's quotes and doesn't mention Zelda quotes). I know I'm being a bit paranoid here when I bring up copyright stuff, but I'm not kidding when I mention zealous lawyers laying down strict rules...
This is only the opinion of a user on the outside looking in, but I'm not sure there's any sensible reason for this being in-- at best it's a waste of space and code, and at worst having Lovecraft spouted during an could be seen by the user on the receiving end as being in poor taste. (Speaking from experience a month or two ago, when a build of ed after ages of tring to compile it)
I think that it should remain in. It sort of reminds people who stumble upon this that has indeed been built by real people :-) I also don't think that it is somehow "unprofessional", every program I ever came across has some sort of an easter egg in it,including Git, (starting with its name). Having this compile only with a certain opt in flag kind of defeats the purpose, but maybe a flag that can explicitly opt out of this kind of thing is worth having for embedded developers. There's no sensible reason apart from having some fun, I think that's enough of a reason, but opinions will differ.
It's not part of , it's part of the runtime and is included in every Rust program without . An easter egg like this in is different than putting it in every Rust program.
I suggest its removal simply be the christening commit of 1.0-stable.
yesssss
To those of you saying "2k, in 2014?" I will point out that there are a lot of platforms out there where 2k is still a big deal. If Rust is going to work for embedded systems work, you can't pull tricks like this.
those would not be using Rust's runtime anyway, and so would not have this in it.
Why should we have poetry in a binary executable generated by a supposedly serious, non-esoteric programming language? One would think this wouldn't even need to be a discussion...........
that is not necessarily true. As I understand, the runtime is getting slimmer and slimmer with every RFC.
aye. To my tastes, this sort of easter egg belongs in the compiler/toolchain, not a statically linked stdlib.
True, it probably shouldn't be part of the runtime.
An embedded gag that only comes up when the program is frustrating the user with a catastrophic error?
Honestly, as someone outside the Rust community, seeing this puts me off using the language. I'm a Lovecraft fan, and if this was an easter egg in the toolchain I would love it, but embedding this statically into all the binaries I ship to end users is a step too far. There's a lot of negative interpretations a snooping end-user could get from finding these quotes talking about things dying and gods in the binaries (and running on a binary isn't exactly difficult). That negative interpretation would fall on me, who they see as the developer, not the Rust team, who they probably don't even know exists. Rust is a tool. If my table saw has a tiny inscription on the underside with the name of the engineer who designed it - that's neat, a fun homage, and overall great. If my table saw contains a tiny router that engraves that engineer's name onto every piece of wood I cut with it - not so great. It degrades the quality of the tool. While I appreciate the entertainment value of the quotes, I think moving them into a developer tool like the Rust compiler would maintain that entertainment while also not degrading the quality of Rust by inserting unwanted data in generated binaries.
That's an incredibly fitting analogy. Here are a complete outsider's 2 cents: why not change instead to display a funny (or lighthearted) quote when something goes wrong, to sort of alleviate the pain of having your compilation fail? Of course, it shouldn't get in the way of you solving the issue (or it would be even worse), but if it manages to have some "decorative" value, I think it would be a perfect middle-ground between getting rid of this easter egg entirely or moving it to a more sensible place.
I am very much in favour of removing the quotes. Put the quotes somewhere where humans will read them, not machines


See I propose to change the license of Non trivial contributors: OK OK OK (MoCo employee) Contributors appearing in git blame that are trivial (trivial update due to language changes): OK (MoCo employee) OK OK (MoCo employee) OK OK OK OK OK OK (sent agreement to by email) Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the computer Language Benchmarks Game license (
We don't need statements from Graydon or Marijn as they both contributed as employees. On Jun 7, 2014 5:50 AM, "TeXitoi" wrote:
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
Op updated. could you please respond?
Citing in a private email: can I consider the contribution of negligible? the same for renaming? If yes I can propose a PR for this and for
guh, I suppose so, though I'm disappointed that didn't cooperate.
My change is obviously trivial and I have zero copyright over anything to do with the shootout benchmarks, but if you must, then: I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
OP updated. Thanks. I'll wait some days to see if respond to my email.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()


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


(sorry about the bad title but I really have no clue what's going on here!) Compiles and prints . I think it's getting at the of the inside a . edit: As one might expect, does not compile.
Seems rather bad. cc
Nominating.
This is a fun bug, it's by far not limited to the operator. I tried to reduce the test case a bit, starting with a new non-operator trait, changed it to a static method that just returns for inference, and...
cc me
Assigning 1.0, P-backcompat-lang.
Even smaller:


At this point, and both exist. Just in case it matters: my prefix is .
Fallout from , perhaps? This isn’t the first time we’ve had completely broken (two months ago it happened, ). Why don’t we add it to the tests done on the buildbot?
Indeed, this was predicted as a known consequence of . It may be the case that asking people to set is too much. We might need/want wrapper scripts to drive that set up such environment variables, much like other projects have.
Fixed by .
(see comment , since it is relevant to this issue.)


A fixed-length array expression with a repeat count with the high bit set and no suffix is incorrectly treated as a negative count. On a 64-bit machine: This results in
Can be easily fixed after landed
Seems that it is not an issue any more.
I'm thinking that if it behave differently on different platforms, is it making it an undefined behavior? And I think designating an exact behavior for UB cannot possibly be a breaking change?
This does not make it undefined behavior. It's very much defined behavior. If it were undefined behavior, then any or literal would be undefined behavior as well, because the range of valid values is architecture-dependent.


We should record the names that users give complex types and use them when we can when reporting diagnostics.
WONTFIX (not require for bootstrapping; works correctly in rustc already).


fails with vector v.
WONTFIX (not required for bootstrapping, reopen if somehow this re-emerges in rustc)


On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.


The std docs should list: The version they were built with The build date They could be at the top or bottom of every page, or on a stand-alone page like About or Help. This may not be important on rust- where I think they are rebuilt with every push but it seems like a good idea. It might be more useful on other sites where it isn't rebuilt for every push.
I don't think this is a problem with std itself, since the version is in the URL (or it's master, which was built in the past 24 hours).
Not sure where you std docs URL doesn't list a version. I don't think it will be a problem for Rust long-term. Once stable, the address will probably be something like with version varying between versions.
Partly a dupe of
Yes, this is basically a dup of /


Normally when a static variable has a recursive the definition, the compiler issues an error. However, if the static is used (and not just defined) rustc overflows its stack. This program causes a stack overflow: Stack trace:
Constant checking -- which detects this recursion -- occurs after type checking in the phase order, but type checking needs to evaluate the constant expression in order to find the length of the array type. It looks like strategically inserting a call to in the appropriate place would fix this at the cost of potentially performing the check many times.
After some chatting on IRC, it looks like the best way to fix this is to break the item recursion check out into a separate pass that comes before type checking. This is my first time looking at this part of the compiler, but I'll give it a shot.
This approach looks promising. I need to do a full build/test run and then I can submit a PR.
Fixed.


Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.


Couldn't find another issue for this. The error message for this is poor and should suggest qualifying the type, or at least clearly saying that a value from cannot be used as a type, and the span should then help the user understand (it is currently fine): Error message comes from astconv, so we could probably catch this in resolve?
(I'll update the example so that the bug is still demonstrable.)


Hi, I've been giving rust a try and hit my first compiler bug today. I was playing around with traits and ran into an error with the following code: In particular it seems it's the last line in that breaks things, if I comment that out it compiles (and runs) without issue. Here's output from rustc: I am using on OS X 10.9.4
Looke like this no longer ICE-s: Now produces: Which seems like the right error message. Please reopen if you are still having trouble. Please reopen if you are still


Some of core methods using macros. Like and of and . I found two primary things about this: () (, ) Seems like some of fail (panic) methods will be preserved (like for a ). But using of such methods is highly error-prone. To prevent mass usage of them I suggest to mark such methods as . For example:
is used for operations that are memory unsafe. marking (supposed) code smells as would only pollute when or when not to use it. notice memory unsafe is a very clear definition, unsafe does not mean this code might be broken, per se. (as i understand this)
is for drawing a boundary between memory unsafe and memory safe code It's not used to discourage the usage of safe APIs as that would break down the boundary and make it harder to identify memory safety issues. Usage of and is common in correct code, because there are invariants that are not encoded into the type system. Changing the meaning of would be a fundamental change to the design of the language / libraries so it would need to go through the RFC process (but it wouldn't be accepted).
(now at )


Let's say that you have a JSON document similar to this: And the value of can be either a number or a string. There is currently no way to write a generic implementation of that can handle this. Attempting to read the value of will remove it and throw it away, even if the read triggers an error. You can't try to read a number and then read a string if it fails. The element is returned in the , so it should be possible to write an implementation of specifically for Json, but if you do so you can't put the object within another object that has .
Can it not map to the enum?
The enum doesn't implement . It's probably for this reason.
Duplicate of Should I close this?


Code: Compile, run, result is Sorry, cannot find smaller example to reproduce the problem. Similar code, internal compiler error:
Smaller:
Looks like a libstd bug: could you file a separate issue for the internal compiler error?


Noticed in . This is either a really odd way to ask for the version, or a bit of advice that's no longer relevant. What should we say instead? is a bit too_ verbose — I killed it after it wrote 8.1 GB of logs compiling .
I think the intent was indeed to get the version output. I think the phrasing is only odd in that it does not make that intent clear. (It is possible I am wrong about the intent here.) But there is an additional problem: Sometime between 0.10 and 0.11, we revised the / output to ensure it would be only one line when you do not supply an argument to . This means we lose potentially relevant information, namely the host system type (e.g. or ). We could fix both of these problems by revising the instructions to say something like:
Closing since was merged.


When trying to do development on the stage1 compiler, I've been hitting a link error. I suspect something has gone wrong in our make dependencies because I think the problem goes away if you first do a full build before doing (I think, though I have not double-checked that scenario from scratch in a clean build dir yet).
Also, needs to be written much like itself, in that it needs to be able to build under a snapshot compiler. I have been encountering issues with its use of slicing syntax due to how the associated feature gate has come and gone.
I know there is well-founded opposition to gating a PR on passing, but wouldn't just adding to the set of required build products at each stage during boot strap prevent errors like this in the future?
(sigh; the issue may be isolated to the snapshot compiler ... my attempts to reproduce with have not managed to duplicate the problem here...)
So at this point its probably not feasible to fix the issue as described here, since I am pretty sure it is isolated to a problem in the snapshot compiler. But we can and should still try to increase the coverage of bors to handle at least building from a snapshot, if possible. (Maybe its more a problem with how we check the state of our snapshots?)
At least building seem reasonable! Running the tests may end up just making a longer cycle time longer unfortunately :(. (but compiletest is fast to build)
In case anyone is curious, the problem also occurs on Linux. I would be curious to know if taking a new snapshot would fix this. I'm not exactly sure how best to test that theory; my attempts to use to test this theory have been somewhat flummoxed by different problems.
It does indeed seem like if I first do , after the but before the , then things proceed just fine. This is evidence for my original hypothesis that something has gone wrong in our make dependencies. (odd that i could not reproduce the problem via another build though. Then again, there is still some weird rpath-ish stuff in our OS X builds of that I imagine could easily mask a problem like this.
(PR only fixes the build issue; it does not attempt to add to the bors cycle.)
(PR also does not actually fix the problem I mentioned in comment: . That can be resolved separately; but I will revise the PR comment to not say that it "fixes" this issue.)
(I edited the PR description but forgot that github closes issues based on the original commit message.) I have a follow-on patch that resolves this in more fundamental ways, e.g. by both fixing the build itself, and also adding rules that will force bors to gate on continuing to build.


Technically speaking the negative duration is not the valid ISO 8601, but we need to print it anyway. This code: Produces: Should be , in fact Should be , in fact
Cc


Linking may fail when an incompatible installation of MinGW is on the PATH, because rustc ends up running external linker instead of the bundled one. I keep seeing people running into this problem when using WIndows installer. The solution it to run rustc in a console with stripped-down PATH, but this workaround is very nonobvious. I am afraid this will negatively affect perception of quality of our Windows distribution because many early adopters will have some version of mingw already installed on their machines. I think the earlier decision to make rustc prefer bundled binaries () was the correct one. We should un-revert , and fix cargo build instead.
cc , , rust-lang/cargo
Regarding cargo, I think we can take one of the following approaches: Use the snapshot compiler. Specify linker path explicitly via . Delete/rename directory after installing. Add a new command line flag to rustc for controlling this behavior. Perhaps something like ? cc
Issues like are definitely quite worrying, but I would see this as more than just a problem with Cargo but also extending to any project relying on libs installed on windows by some compiler toolchain. The bundled gcc doesn't know anything about system lookup paths, and I see this as akin to saying we should run gcc on unix with no default lookup paths (which would likely be disastrous). I suspect that there are other projects which rely on libs coming from a MinGW, and this seems similar to relying on randomly installed libraries on unix systems, so I'm not sure if it's necessarily a bad thing. Do we know why the error in is occurring? It looks like there's an incompatibility with the MinGW installation, but do we know precisely what it is? I was under the impression that linkers were intended to interoperate well...
I don't really want gcc to be able to find arbitrary mingw libraries because I don't want Rust users on Windows to depend on mingw (imagine cargo packages that expect mingw libs but only a fraction of windows users actually have it installed). I've misunderstood the implications of this issue before, but my inclination is to do the revert and make the cargo build do the extra work to get at the libs it needs.
Nominating since this issue gets hit pretty often and is the last major usability problem on windows.
Not quite: mingw gcc has a default library search path built-it, and it is expressed relative to the installation point. So the one we bundle is going to look for libraries only under (unless we supply more via , of course). This is mostly about library compatibility, not about linker. GCC may emit references to library symbols, that may not exist/be buggy in older versions of mingw. This particular one probably happened because the developer had installed mingw with sjlj exception handling, which defines UnwindSjLjResume instead of UnwindResume.
Assigning P-high, 1.0.
Not being able to access the full set of mingw libs means that people can't link to random GNU libs (which I'm in favor of). I'm unclear on whether it also prevents people from linking to various windows system libraries (I have this vague idea that mingw includes artifacts that make the linker able to link to e.g. ). Is there any concern there?
gcc needs to recognize system library (), so picks up . We ship , but we don't ship or so , rust-lang/cargo, and occurs. So, what's the role of bundle? I thought bundle is for providing "minimal" linking environment so that beginners can build hello-world without installing mingw-w64. In this scenario, if user want to do more than bundle can provide (e.g. gdi32), user must install mingw-w64. At least, this is current status. Maybe we can bundle ? is 72M.
Preferring bundle means: if user has old mingw, will not use it. This solves lots of of beginners' issues. , if user really wants to use their own linker, user need to do something. This complicates build story. So my suggestion is 1) prefer bundle and 2) add a flag to not use bundle at all (rather than changing preference). Maybe or ?
on the other hand, there are a few libs that need to be matched to the version of gcc that Rust was built with. It's mostly stuff like and ; possibly also ,. So simply deferring to external linker probably isn't a good idea, unless we ensure that our bundled libs are being found first. I kinda like the idea of shipping the minimal set of import libraries that is sufficient for linking Rust's standard library. We could add a few more common ones like , but everything is a bit much, IMHO. For reference, here's the list of import libraries that D ships with: , , , , , ,, ,, , , , , , , , . Btw, mingw can also link to dlls directly, so in many cases adding to the command line is enough.
ld can also link to dlls directly? Is it possible to #link directly in them in source? #[link(path = "%systemroot%system32")] or something like that?
That D ships a set of system import libraries is encouraging. Though if mingw can link to dlls directly it's not clear why this is such a problem - if we were to just have rustc add the system32 path by default would this problem with windows import libraries go away completely?


The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.


For example: This can be a little more clearly seen with the IR generated for main: Note the lack of anywhere on .
Triage: this is still true today, though needs to be updated to , and there's now a warning about not being a valid foreign type, which is irrelevant to this particular issue.
claims it repros still.
Updated test code: Still fails to compile with the same errors mentioned in the top post along with the irrelevant invalid foreign type warning mentioned by


This was the smallest I could make it. Commenting out the lines for either or or making and the same type allows compilation to finish successfully. Error: What I don't understand is: why in the world is it even complaining about implementations when no one is using ? Is this some sort of weird interaction with trait object types? (rustc at commit , Linux)
I've been seeing this too, any time I have a trait with two associated types that are different. Still happens as of the current nightly. Strangely, if you make them the same (i.e. "type T0 = f32; type T1 = f32;" in the impl), the error goes away.
This seems to be fixed. The example compiles on


Here's what I think is wrong: keywords , and appear next to the name of the constant, when clearly they are redundant. the constants page through search brings the user to an empty page. value assigned to the constant appears along side its name. When reading the documentation of constants, the most important information is the name of the constant and its description. Having the declaration appear inline makes scanning for the name of harder. Better output would replace the declaration with the name of the constant followed by its type. Also it would move the declaration of the constant to the empty page mentioned in point 2 and have the identifier of the constant link to this page. All these points are relevant for statics as well. Example of ugly output: ! This page should show the definition and a description of the constant: !


The documentation is misleading. The pointer is not allowed to be null.
How do you make an empty slice if the pointer is not allowed to be null?
The underlying representation is an implementation detail and shouldn't be documented beyond the ability to convert the raw parts obtained from a vector back into a vector.
The language and library documentation has a love affair with making far too many promises about the implementation. In the vector module, there are numerous errors when it comes to information about the vector's capacity too. It tends to guarantee that the capacity is exactly what was asked for rather than at least that much. It is allowed to set the capacity to a value provided by the allocator.
Does that mean you are required to special case the empty case and then use a different way to make an empty vector?
No, it means you can't use this method outside of the standard library beyond converting from an existing vector.
If what you're asking is how it does this internally, the answer is that empty vectors along with zero-size allocations in general are allowed to be entirely arbitrary pointers. They will never be dereferenced and the compiler / library code will never attempt to deallocate them.
The documentation is not supposed to cover these implementation details. It would make sense to cover it in comments (which it is) or internal design documentation.
In that case I suppose the docs should say: can only be constructed from components of an already existing vector.


cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.


Tracking issue for this failure:
It appears that the compiler is producing corrupt metadata somehow. I have modified the test to ignore and only link to , and I've found an interesting phenomena. When running the test via the rlib for -2 may end up containing two blobs of metadata. One blob of metadata ends in four 0x0a bytes (corrupted), and the other blob is the exact same but without these trailing bytes. The compilation of the -3 crate is the one that's failing, and it will deterministically fail depending on the metadata of the -2 crate. I do not currently know where the extra bytes come from, still trying to track that down...


Right now we don't normalize impl bounds during method probing, which means that the winnow stage may not work great when those bounds involve associated types. I think with the new setup we should be able to do this but didn't have time to test. Search for the FIXME in


I think I found a bug with non-power-of-2 SIMD vectors. They're randomly turned into zero values when I store them on Expected result: What we get: Tested with:
As you can see, this is a fault of assuming (while for this is 12 and 16 respectively). More accurately, for , every growth allocates bytes while it actually needs bytes; any element after will overflow the memory, and they will be omitted at the next reallocation.
Ack!
CC
I've got through and I guess there's something wrong with for and other non-power-of-2 SIMD types.<!-- (Don't trust me!) --I think now we've got 2 available options. Make always true even for non-power-of-2 SIMD types like . Make function properly even for situation. I'm pretty new with Rust. Someone pleaes make me an advise!
I'm not sure what the exact behaviour should be. Part of the problem is that non-power-of-two SIMD types don't exist on most platforms, so it gets widened to whatever it needs to be. However, an f32x3 is still only 12 bytes of actual data. I think that Vec should handle the case anyway. Whether the case should come up... I don't really know.
Given that sizeof (f32x3, u32) == 32, it seems like rust already adds padding for SIMD types, so it's simply sizeof that's broken, and should include the padding. At the same time, Vec<Tshould probably assert that sizeof T = minalignof T to catch any errors if in the future there are any types where their size is less than their alignment.
Nominating because the required change may be a back-compat change to some primitive semantics.
Actually, thinking about it some more. I believe that the current behaviour is correct. doesn't account for padding, because padding is situation-dependent: has 7 bytes of padding after the , but that doesn't stop from being 1 byte in size. Just because the type gets padding, doesn't mean it needs to change size. The whole point of having a different alignment to size is to cover these kinds of cases, where the number of usable bytes is not a nice integer multiple of the alignment.
In that situation, the extra padding is to meet the alignment requirements of "u64", not the "i8". In the SIMD example, the extra padding is part of the SIMD type. ie. for (f32x3, u32) there are 4 bytes of padding between the fields, even though u32 only requires alignment to 4 bytes. Either the compiler should not add any padding and sizeof (f32x3, u32) == 16, and any accesses take care to preserve the u32 or as is more usual, the SIMD type should include it's padding. edit: To clarify, types do include their padding in sizeof, which is why sizeof (u64, i8) == 16 as opposed to 9
Amusingly, has a size of 16, whereas f32x3 on it's own has a size of 12, which really shouldn't happen. The issue is caused by sizeof being implemented as a call to this function: The comment above the function is wrong: LLVM does include padding when calculating the size of types, but only for structs (not for vectorised types), which makes that function fairly useless and definitely not the preferred option as the comment suggests. should be preferred instead which always includes padding, so is at least consistent.
NB. and are experimental and are highly unlikely to be stable at 1.0.
Current works like below: and I found that current LLVM doesn't have any guarantee between and . Instead, for SIMD vector types, is guaranteed to be greater or equal than . For example, and of 80-bit floating point format is and . I know that Rust doesn't have but if it does, will be and will be . Which means would have same problem. Now I see 2 options here call , not (as said) function properly even for situation. → → → → → → → alignof → → → → →
I meant more-so the size_of semantics, but simd semantics might also be affected.
I think this is a compiler bug. There are many low-level APIs assuming that size is a multiple of the alignment...
For example, C11's function requires that is a multiple of the parameter. It's expected that the compiler will always output sane values for both (unlike :P) so it is a sensible limitation.
Unfortunately, forcing to return a multiple of would make impossible, which seems like a big missed opportunity. Perhaps there should be a function that just rounds to the next multiple of ?
You could have both sizeof and paddedsizeof, but for the moment, they'd both have to include padding because for struct types LLVM provides no way to get the size without padding, and for vectorised types, even sizeof should include padding as can't be applied to vectorised types without masking every load/store to avoid overwriting the u32 in (f32x3, u32).
Currently I'm testing , and it seems to cause no trouble. Please make me an advise if I'm doing something wrong.
OK Let's do this →


Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!


By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"


I've got bitten by: The compiler silently accepts this code, no warning at all, but nothing is derived. (rustc 1.0.0-nightly ( 2015-01-08 17:03:40 -0800))
I get two warnings with a more recent nightly ():
I tried playpen just now: And the output gives: I think it is a clear warning which is good enough.
If one uses the type in a place that needs the derived trait, one will get type errors before any of those warnings appear. E.g.
I've updated to rustc 1.0.0-nightly ( 2015-01-14 00:41:55 +0000). I'm getting same error as Even though it shows an error, I think this is a problem, because it shows a wrong, misleading error — the problem isn't in the line where value is copied. It's in the line which has been ignored. Because of that I've been pulling my hair out and tripple-checking all borrows in my program, documentation etc. and wondering why correctly-looking code does't work.


There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons). I think the best thing is just to add some sort of hashset and check for duplicates in or maybe . But we should do this check after doing full type resolution. I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.
Marking as mentor.
Is there something left to do here? it seems like fix for does the thing suggested in this ticket.
Closing per .


On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.


This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?


with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13: 0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure. 22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code. Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:


The behavior of .consume when the buffer is empty is weird : while :
Currently the contract of is that you can only pass a number the number of bytes you receive from . In this case the method is never being called, causing the weird behavior. I believe this is a documentation issue as the documentation for the method is pretty curt.
Maybe adding an assert_debug to check that could be useful too ?
What's the intended use of if it must always be passed a value the return value of ?
Oh sorry, I meant ! The function is intended to tell the buffer how many bytes you've consumed from the return value of


Slightly smaller example:
Running with code block code block I can't reproduce the ICE. Can this be closed?
Tests in .
Should be closed now,


Reading the current documentation about at it is not clear to me what the effect of is. I was supposing calling this function returns the value stored in the Option type and replaces it by an value. However, this seems not to be the case as the second assertion in the following example program passes fine: (You can run the program online at ). In addition, the current documentation says: Does this means the value contained in the is moved out or cloned or is a borrow taken? Also, is a type and I don't think that the function really returns a type, but a value of type . Therefore, should the quoted sentence maybe reworded towards something along the lines of: Please let me know what you think about these points. I am more than happy to provide a PR to improve the documentation, but I don't know all the answers to the questions I have raised above and I am also not sure if my claims are correct :/
moves the value out of the option if it is , or panics if it is . In your example, the call to performs an implicit copy of because is of type , and implements when implements (as does). This example will not compile, because does not implement : The error is: The documentation could be updated to mention moving, but this is implicit in the method's parameter, which is by-value.
thanks a lot for your explanation! Still, I don't think I grasped how the works completely yet. Here is an example: I understand that moving a value from a borrowed object is not possible and that's why the first attempt fails. However, I don't see why the second attempt works. In a sense, the new type after the call to can be written as with . In that case the call to as done in looks to me again as a move. But as is borrowed, I don't see why this move is different from the first move attempt in my code, which failed. Is there a special rule to the method, which makes the later case work but the first not or am I missing something on how the borrow/move rules in rust work?
Basically, in order to call , you need to have an owned . This is the case in your "ATTEMPT WORKS" code because goes from to . The code under "ATTEMPT FAILED" doesn't compile because is borrowed (), not because contains a borrowed value. For example, the following code does compile:
Thanks again The point that you need an owned makes sense to me and was something I was not that much aware about before :) What I don't see at this point is why in my example is not an owned already. As you can see in this code example: It seems that is of the owning type already. From reading your last comment it sounds to me that is supposed to be of type with here. But that is something I don't see yet :/ Any comments is highly appreciated! PS: I hope digging deeper on this issue is okay for you? From your comments so far I think I can fix the documentation but still I would love to have a good overall understanding how the interaction with really works :)
In that example, the type of is indeed , but it is not owned from the perspective of the compiler, because it is accessed through a reference ().
Ahh, I think now I get it - thanks a lot Are these the (hidden) steps the compiler is doing when executing ? The compiler knows that is of type The definition of is given by , which means for calling the , the must be a mutable borrow. As the is NOT a mutable borrow, the compiler takes an implicit mutable borrow like and uses the result as the argument when calling . The call to does type check and returns a fully owned type. Here I am using the term "fully owned" to differentiate to the case of the previous which is not owned due to the access through the reference of . Because the result of is now fully owned, the call to type checks. I've got to say: I love and be impressed what the rust compiler is doing underneath here (once you understand it :) )! thank you sooo much for these helpful and very educational comments!!!
So, given all this: is there anything actionable we can do to improve these docs? What would you suggest, ?
how do you feel about this: the description gave as sounds much better and is more precise compared to the current description of , which is . Therefore, I would love to exchange them. do you think there is value in adding a section about and how it works to the existing documentation?
I like it! would you like to submit a PR or should I take care of it? I'm not sure.
I don't think we need to add anything about , because there's nothing special about it. It just follows Rust's ownership and borrowing rules. However, 's documentation in general does need work, both convention-wise and content-wise.


This affects the test suites for the and crates.
triage: I-wrong, P-high (1.0)
triage: P-high (1.0)
I ended up adding the 1.0 milestone by hand; isn't the above note with supposed to do it?
cc
the log above says that highfive did add this to the 1.0 milestone - it might just have been that your local view of the webpage needed refreshing?
yeah I guess so, I don't know what happened anymore. Maybe I should have given highfive a little more time to react.


For example  should have a bound, but we're a little too aggressive about pruning out the bounds. For comparison  does indeed have the bound. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This also applies to bounds on traits.
This prompted a question on IRC about whether requires , because the bound is not visible in the libstd documentation. It is visible in the libcore docs though.
Triage: This still happens
This actually ended up biting me today, is there a plan to handle this? I could help implement if I get pointers
did not fix this - it now shows , which is nice, but it doesn't show bounds on traits. For traits it does matter because the default is .
I would start by finding out why this is different between local crates and cross-crate re-exports. I expect is behaving differently from .
Ah, I also hit this today when looking at . Kudos to whoever can figure this one out :)
claim


If you have a function like this: we should report an error. The only thing you could legally do in that case is fail or return a static item, so you miight as well write: This sounds like a good lint warning/error.
My vote is warning rather than error. If you're right that it's always the wrong thing to do, then you shouldn't be able to write non-unsafe code that does this that doesn't error somewhere else. And maybe you want to try doing it just while hacking / experimenting with the language.
Reproduced with This compiles successfully.
Not critical for 0.6; removing milestone
Reproduced with Still compiles successfully.
Nominating for milestone 5, production-ready
just a bug, removing milestone/nomination.
Visiting for triage email 2013-07-22 reproduced with
As of lifetime elision () we now indeed require a bound in that position. Closing.


I build rustc from source with to get output from to chase down an ICE, and the resulting compiler is about 25 times slower than Nigthly on the same commit. (Servo’s script crate takes ~50 minutes instead of ~2 to trigger the same ICE, .) said on IRC: … which would explain the slowdown, but I didn’t find an issue filed for it, so here it is. This may be a Makefile issue: .
See and . The latter is specifically about optimizations and supposed to be fixed by . Is this still a problem (again) or are you building an older version of the compiler?
Oh you can explain it in different ways, see
should be good enough btw
I’m building 2015-04-25. I believe (which I had found) is not related but kind of is. I can try as suggests, but since lists and not I was lead to believe that enabling optimizations was the default. Is it not? Or is is tied to ? If so, why?
i think this may be "by design", according to discussion on and . Although then again it is not clear that there was consensus on that should imply (though my reading of the comments there that at least some of the participants were in favor of it having that effect). The intention, as I understand it, is that if you do , then you want an "ideal" environment for debugging, which for some people implies "do not let LLVM optimizations get in the way of my debugging experience." The problem with this reasoning is that bootstrapping takes an absurdly long time with . So in practice I do not see how one could realistically actually use without also including to override what it is doing today. (At this point I essentially always call via a driver script that passes explicit switches based on local filesystem context.) Anyway, I would not object if we went back and again decoupled the configure setting from the configure setting. (The argument for why "should" imply , as noted in the relevant , was that 2-3 flags for configure the build is too many, and therefore we wanted to identify two "modes": release mode and developer mode, and then choosing your mode via would yield the "ideal" experience for that mode. This all sounds fine, but I clearly take issue with the claim that is part of anyone's ideal developer mode.)
I can imagine the logic behind this, but in practice this is far from ideal. It’s only one data point, but here is how my thought process and experience went: I hit an ICE and I don’t know the exact cause Asking on IRC, I’m recommended to retry with There is no log output. I assume logging is disabled on my Rust build I decide to try making another build where they’re enabled. I look at . seems relevant, it probably enables logging. I note that is listed as an option, but is not. I assume this means my build will be optimized. This is what I want. The build is taking a while. I know Rust takes a long time to bootstrap and all, but this seems longer than usual. I go do something else. The build ended up taking just over 4 hours. I start building Servo with this new rustc. Cargo somehow decide to rebuild everything, even though I was careful to pick the same Rust commit. This takes another 2 hours, instead of the usual ~8 minutes. Every rebuild of just Servo’s script crate (where the ICE is triggered) now takes over 50 minutes instead of ~2.
Reopening: while documentation helps, I still think we should address the root problem here. See: (And maybe I'll just put up a PR changing the configure script to make it stop doing this.)
I agree with and that in practice you do not want to disable optimizations, and we should not do so without an explicit . This is extra true now that the debuginfo includes inlined functions fairly reliably even in optimized builds (at least on linux): getting a complete backtrace was the only reason I ever resorted to in the past, and it was always painfully slow.
This still seems to be the case, but hasn't been motivation to fix.
This bothers me every time someone accidentally does it, but I didn't even know this issue was open.
I still think we ought to change it. =)
Maybe we can force people to choose between and when is on. That way you can never misunderstand the role of . Like, when we trigger an error: Edit: I forgot we already switched to rustbuild, but you get what I mean
I'm still waiting for someone to come up with an usecase for an unoptimized compiler.
I thought you are the one who may find some clues. Doesn't it help you to decide a tricky behaviour of a compile result is caused by LLVM or rustc? I have no idea.
in theory yes, in practice I've yet to have such a bug (well, I did have one once, actually, but I didn't find it by turning off optimizations); in general an unopt compiler is just too slow to use.
Isn't this fixed by that is, these are all separate options now.
still exists and rustbuild reads .
also, regardless of the existence of , the code for building the bootstrap config from the still ties them together; see here: note in particular that bit about how the is established by the presence of the setting, and then that affects the default value for if it hasn't been explicitly established in the . My proposal is that we stop having the default here (solely for bootstrap builds) be affected by the setting for above it. (And update the docs/messages elsewhere in e.g. accordingly)
Note also that the doc comment for doesn't mention the influence of on its value. It gives this dire warning about having set to false, but the implication of the doc comment is that its always defaulting to :


I'm not sure if this is an oversight. But the implementation should be trivial. I'll add tests and implement it, if it is fine.
Strings aren't indexable and .len() doesn't count the number of chars. :smile: What comes to mind first is an iterator inspecting the two first chars:
xD I didn't test my code, but you get the gist. I had a impl at first, but then edited it
cc
Triage: this has not been .
PRs welcome!
I can take this. I was also thinking of adding a impl for , but unsure if it would be better to wait for to get closer to stabilization and use that instead of adding another empty enum to std
wait, that wouldn't work bc of lifetime issues regardless, right? :(


blksizet on 64-bit FreeBSD is 32 bits, not 64. on FreeBSD x8664 yields: yields: I tracked this down to the type definition, which is unconditionally 32-bit on FreeBSD (see , noting this line: this is unconditionally the definition of on FreeBSD - whether on 32-bit or 64-bit platform.)
Also, is a no-op (two fields of size 0) on 64-bit FreeBSD, the field can be deleted from the structure.


The following function can drop any object arbitrary number of times, using only safe code: Probably bad :) Found while researching
Nominating for P-high
cc
Too bad this doesn't just cancel out the Leakocalypse :stuckouttongue:
(well, any object that implements . But yes, I see the point being made here.)
look, no required. I guess it doesn't work for types that are already unsized.
to be clear, I am looking at this now as well. :)
I guess is related.
I hope it is unrelated. In particular I wrote this on that ticket:
Yeah, it's unrelated. The call happens for , which does need drop.


The grammar of given in the is outdated: the mandatory semicolon at the end of the first rule is missing, and an alternative notation using the curly brackets is missing as well. Regards, Ivan


This takes ~2 seconds to type check (according to ): Doubling (respectively, halving) the number of invocations multiplies (resp. divides) the time by 4. It applies to arithmetic in s/s too which is, I imagine, where this will occur most often in practice (it's how I found it). Observations: for , , and , annotating either side (e.g. ) or both sides makes it take only 0.03s and behave linearly (AFAICT) for and : annotating the LHS () reduces the time to ~1.5s, annotating the RHS () reduces it to ~1.1s but both are still quadratic, annotating both takes it to 0.04s and linear it seems to only be dependent on the number of operations in a single function/item, separating the 4 big chunks above across 4 functions reduces the time to ~0.5s. there's no significant difference between using the macro or writing the operations inline (I only use to allow easier experimentation) cc
This must be what's making my old macro-abusing inflate implementation take almost 300 seconds in typeck. It almost sounds like type-checking a function is quadratic over the number of inference variables. Having ran callgrind on the sample and also half of it, I'm seeing the following trace: An unrefined conclusion is that either shouldn't call or should be constant-time.
Is this the same issue as ?
I'm not too familiar with fulfill and infer, but couldn't track the latest snapshot it processed and look at the new information there?
We have exactly for this reason. It doesn't work for some reason tho.
This is the same issue as This is a different issue from (I think I will fix that one separately).


All of the following I'm going to describe happens only when expanding doc comments in a macro, using meta fragments, in other contexts it works fine, so it indeed is a thing! A sample of doc comments expansion in a macro can be found at so I'll skip samples and go direct to the point. If I use a escape sequence of usual strings it seems to expand it right there on rustdoc. I have found the issue by trying to do something like the following: When I run I get this panic: When using the outside a code block it does not happen, but if I try a hexadecimal literal outside the code block instead it still panics. I get Interesting but let's try something that is not a null character to see what happens: Ha! I get a in my html output!


This does generate code that calls in the vtable, but is not particularly useful. cc
Still a problem?
It's still true, but I'm not especially worried about it.
Isn't it a bug that you can declare such a trait at all? There's no way to implement it, right?
This code is now rejected with:


Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.


Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.


Some : The Lifetimes chapter currently has: which does say "declares our lifetimes", so maybe further explanation isn't appropriate here, but it looks like the Functions chapter is sticking to the bare minimum. I'm not sure where this would fit, but I think the could use another sentence or two of explanation-- "This is where you declare lifetime and generic type parameters that this function is going to use" and link to the appropriate chapters for that perhaps?


Tracking issue for the feature, which is  and the associated enum.
Yes, please. Why? Makes little sense.
I disagree that it makes little sense to expose getters, it's possible to envision a situation where one formatting is composed of many others and you perhaps want some to be formatted to various widths or perhaps enable various flags (e.g. the "alternate" mode). It's certainly niche but it's somewhat necessary for completeness.
, , and all seem straightforward and can be stabilized as-is. I would also very much like to add and stabilize boolean accessors for the various parts of : , , , and (we could call the last one but that seems like a genuinely excessive name). It's pretty unfortunate we stabilized the accessor in the first place IMO, but oh well. I'm a little less sure about , though. What is returned if no fill character was specified? Why doesn't it return an like the others? Is sufficient? Should it be a full grapheme instead?
I'd be fine just deprecating the method (it's basically useless without constants anyway) and adding boolean accessors, I agree that it better matches design in today's Rust. I'd also be fine making return an and just specifying that it's always one unicode character (it's how the format string is parsed). Perhaps in theory a grapheme could be specified but that seems like something for an even fancier formatting system!
This issue is now entering its cycle-long FCP for stabilization in 1.5 The accessors being in will also be considered for stabilization.
Ah, and may be good to get your opinion on the grapheme-vs- situation here. Currently whenever something is formatted you have the ability to specify a "fill" character which for when padding is applied (normally this is just an ascii space). As points out this fill is currently just a , but it could in theory be a grapheme in terms of "one thing on the screen". Do you have an opinion either way in that regard? Curious to hear thoughts!
Uh. It’s not just graphemes. The whole // thing in as currently written is based on some assumptions: ’re printing to something that (like most terminal emulators) align text on a grid . Unfortunately, as often with Unicode, it’s complicated. Not only grapheme clusters can have more than one code point and still only use one slot (with combining code points), but most characters of some Asian languages and most emoji are “full width”: they’re twice the usual width in most monospace fonts. Control characters be displayed. Or they might be interpreted by the terminal to move the cursor around. has some more background. Here is an extract, about emoji flags: Our best bet for ”what is the width of this string?” is probably That leaves dealing with if it’s double width or a control character. If we want to do it, could be an arbitrary string rather than a single ? Or should be rejected?
Hm, those are very good points! I would be mostly tempted to just pare down everything and say it largely deals with ascii only (and maybe simple unicode?). I don't think it'd be too beneficial to start getting full-blown unicode-width support in libcore just to support a use case like this. Having some verification in the compiler, however, to make sure you're not doing crazy things seems reasonable? In theory, yes. I'd also be fine with this!
The libs team discussed this during triage today and the decision was to stabilize.
Triage: looks like this was stabilized, closing!
is still unstable, linking to this issue:
I am a bit confused about the reason is still unstable. Is it because is only available from ? Is there anything I can help with to move this along?
Nominating for stabilization. I suspect that needs to be re-exported in std, but that seems like something trivial to solve while stabilizing. The only concern that I see left is that there appear to be 3 separate, but equivalent, definition of the enum in the various libraries. These should probably be de-duplicated, but again, since only one appears to be public, we can probably do this trivially as well during stabilization.
I think we should remove and return an instead, but it seems reasonable to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.
Shouldn't this get merged then?
Yes, with FCP to stabilize completed, the next step is a stabilization PR.


This compiles and runs without warnings: I at least expected the unused attribute lint to catch this
They are not ignored, it's just that attributes on item macros apply to the macro expansion rather than the resultant item, e.g this errors as expected as the macro isn't expanded.
Ah, and they're removed when the macro is expanded, which is why the lint doesn't pick them up.
Yeah as noted this is actually working as intended, so closing.
I still feel uneasy about the lint missing these attributes, but I guess that cannot be fixed unless the attribute system is rewritten


When you search for something on the online docs (which I assume are generated using cargo doc) a list of results comes up. When you clear the search bar/press the X button it probably should clear the results to allow you to view the original page. Anyone know how to fix this?
I don't believe that we have anything set up for that. Is there an "X" button? I don't see it anywhere. Regardless, clearing the box or pressing escape or something should probably clear it, for sure.
! And then after clicking the "X": !
Search field is and therefore it might have various user agent specific functionality. Simpler way to reproduce in a cross-UA way would be to follow these steps: a search query; the whole query at once by highlighting it and clicking backspace, delete or any other relevant button; Result list not changing. We could go back to the page that was open before the search field was used to fix this. Note that we do know what page it was, because we simply append to the URI of the page we start the search at.
I took a shot at it and in the half an hour I dedicated to it, all I found that search code is a complete mess and this might be harder to fix correctly than it might appear at a first glance.


When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


The first section on can be difficult to understand for novice programmers, particularly the line "Anonymous functions that have an associated environment are called ‘closures’, because they close over an environment." It's difficult from this context to understand what "environment" is referring to.
Yeah, this definition is kind of embarassingly self-referential :sweat:
I'm going to try to clarify this.
fixed this


After some discussion about the libs subteam decided that iterator adaptors should always preserve the same semantics in terms of the convenience methods and such. This was not audited for when all the initial specializations landed, so we should take a look and make sure that everything adheres to this policy. Additionally, documentation should be to the trait methods indicating what form of guarantees you are given (e.g. calling is equivalent to exhausting the iterator). triage: I-nominated
I've checked . should exhaust before but that's the only bug I found (and it wasn't my bug for once :tada:). Unless, of course, you care about drop order. I haven't tried to reason about that.
The slice iterators () are fine because they are side-effect free.
and are fine because they are also side-effect free.
I'd appreciate it if someone else double checked but I think that's all of them.
This is relevant as well, because implementations of Drop may also (and usually do, in form of memory deallocation) contain side effects. Can we make a [x] list [x] of iterators which were specialised [x] like this?
I strongly disagree. Drop has side effects but programmers should never rely on drop order except stack drop order because drop order is often unspecified (e.g. within structs). core::iter::Chain::last core::iter::Peekable::last core::iter::Peekable::count (fixable) core::iter::Skip::last (fixable?)[x] core::iter::Chain [x] core::iter::Enumerate [x] core::iter::Peekable [x] core::iter::Skip [x] core::iter::Take [x] core::iter::Fuse [x] core::str::Bytes [x] core::slice::Iter [x] core::slice::IterMut [x] core::slice::Windows [x] core::slice::Chunks [x] core::slice::ChunksMut [x] collections::vec::IntoIter
Ah right, this will be decided by anyway.
Awesome, thanks for the work here
Updated list of out-of-order drops (didn't notice ).
triage: P-medium
(Need to make sure this behavior is documented/explicitly promised.)
Is this done? (Everything in the list above is :whitecheckmark:'d)
I believe this is left open as to-be-documented. Also, I don't see any decision as to whether out of order drop is ok.
re-tagging as docs
So I believe that all of these are then documented in Iterator's methods, at least as far as I can tell. Can someone from libs double check me here and help provide any specifics as to what's not documented?
Looks good to me, thanks


After having first read about iterators the TRPL book, it called my attention the scarce number of matching results in the API docs for a query like "iterator adapters". Curiously enough, it looks like the term used there is "adaptors" instead of adapters. Appearances @ TRPL(): "iterator adapters" -7 "iterator adaptors" -1 (part of compilation output) Appearances @ API docs(): "iterator adapters" -1 (book) "iterator adaptors" -158  Appearances found using typical 'Search in directory' feature in a text editor.  Appearances found using the site search filter in Google, ie. "iterator adaptors" Assuming that there aren't semantics involved between these two words in English, I'd like to know what's your opinion on the next steps to take (so we can avoid the inconsistency and possible confusion). What about replacing 'adapters' to 'adaptors' everywhere in the book?
I assume this was fixed by ?
Yes, this issue can be safely closed now.


The following code compiles on stable and beta, but not nightly: For reference, the error produced by the above is: The original test case was reduced down to the above thanks to eddyb and bluss. The original problematic line was (clap → → → boom). Specifically, the issue was with the method, though the error pointed to an earlier temporary as not living long enough. If desired, I can provide a complete, in-context example of this going awry. bluss suggested that this was related to .
cc
Hmm I wonder if the iterators involved need to have the escape hatch for dropck to them.
Here is a variant (that has also regressed) that does not use the macro:
(It looks like may need similar treatment too, but I am having trouble actually making a concrete test illustrating the necessity there -- it seems when I call instead of in the above test case, even stable and beta complain about lifetime issues. Maybe the old dropck is catching something I'm missing in my manual analysis of , so I'm not going to lump that in until I see evidence that it is warranted.) Update: Oh, duh, has a lifetime bound (and a impl), so of course the old dropck was going to reject it.


One minor doc bug: first example should call writetenbytesatend in test case instead of writetenbytes. PS: Is this a good place for website/doc issues?
Yep, this is the right place!


Part of These have gotten some love lately, but should still be checked out.
I am happy with this now.


Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart. :+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!


We need to support references to static items in lvalues. This would be used for accessing a static lock or assigning to a static mut.


The presence in a Rust source file of unusual but useful kinds of whitespace, such as ASCII 0x0C (form feed), leads to the following error: I have a specific use case for form-feeds in source files. But I think in general it is nice to ignore the same whitespace that every other programming language and file format ignores; it lessens confusion for people coming from other languages and backgrounds. My specific use case is the long-standing, but somewhat uncommon use of the form-feed character (which semantically is a separator between pages of text) as a way to group together especially closely related functions or blocks in a file of source code. Text editors or IDEs such as vim, Emacs or XCode provide convenience features to display these form-feeds in aesthetically pleasing way, move between form-feed-delimited pages, and restrict editing to one form-feed-delimited page at a time. It's just a simple convenience feature, but it would really be nice to support it.
+1, I also use this feature and was disappointed when I found Rust didn't treat it as whitespace.
Looks like a fairly simple change could be made to the lexer so it uses instead of limiting to . The only think I can think of is that the function in has been around since before we had a better function and nobody has changed it since then.
/cc , do we want to accept all kinds of whitespace?
I believe we should, yes.


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


Sorting Ipv4Addrs results in unexpected ordering. Ordering is based on the internal representation of the Ipv4Addr without regard to "network order". I tried this code on little-endian architecture: I expected to see this happen: Instead, this happened: Rust playground demonstration:
Ipv6Addr has a similar issue: outputs:


Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.


It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.


When a doctest like this is written: /// /// running the tests will produce an error like: since the test code is wrapped inside a for execution. This is imho not clear in this algorithm description
This seems like a bug somewhere in rustc/cargo, rather than a problem with the docs, because rust /// works fine, but (as was mentioned here) rust /// does not. This seems like wrong behaviour. Also, the suggested rust /// does not work either, I don't know if there is an RFC or issue open about attempting to resolve the names suggested under ... and only showing them if they exist. EDIT: as mentioned below, this is not a bug with rustc or cargo, it's just that there is no way to refer to the current function scope in a use statement if you import a crate into it.
it's not wrong but it is very misleading. The key is that if does not appear in the doc test, then rustdoc encloses the entire test in a main function. This, coupled with the fact that does not really work inside a function, produces the bad situation in which we find ourselves.
Right, it's the 'entire' part that's confusing. I myself find it to be so and I wrote the sentence!
It would be nice if rustdoc used similar heuristics to playbot, where stuff like extern crates and crate attributes get hoisted out of the generated main function.
Why is extern crate even allowed inside of functions? That seems like a horrible misfeature.
It's similar to anything else that brings a name into scope, you can do it in whatever scope you'd like.
I guess the "real" problem is that has no way to refer to a function/expression scope. doesn't work, making the "did you mean" note less than helpful.


As of , we have enabled the LiveIRVariables LLVM pass which is a part of ongoing GC work for . Unfortunately, something in test/bench/task-perf-word- makes the LiveIRVariables pass unhappy. It seems that some LLVM optimization pass is producing an irreducible control flow graph, and LLVM's LoopSimplify pass isn't sophisticated enough to undo the damage. As a temporary workaround, xfails the two tests which break the liveness pass. But we should figure out what LLVM pass is causing the trouble and try to resolve that and un-xfail those tests.
Fixed in , and workaround reverted in .


As a newbie, I made the mistake that can be witnessed with the field in . The way this happened is that I vaguely remembered that you can't use when specifying the fields of and to make sure, I looked up the struct chapter in the book. Sure enough, it said "Mutability is a property of the binding, not of the structure itself." Now, as a newbie, I thought this forbade in field definitions altogether even though it only forbids to the left of the colon and you can still have as the type to the right of the colon. It would be nice if this was briefly clarified for the benefit of newbies looking stuff up piecemeal and not properly thinking about stuff in the context of what has previously been said in an earlier chapter.
:+1: