This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.


Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)


For example, that the struct being dropped has not been deallocated when is called (it's implied by the existence of and Rust's general reluctance to dangle pointers, but still...), and that the struct members are recursively dropped after finishes, and what happens if panics.


It would be nice, if the would mention that the process is detached (and not joined) by default, when a object goes out of scope. Not having a impl is too subtile IMO.
Part of
I'd be happy to take this on. :smile:
Please do! :) On Jan 30, 2016, 11:59 -0500, Dirk , wrote:


Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .


rustdoc source links end in as can be seen here at the moment (the [src] link) Source link is: (Which is a dead link) Also reproduced locally using rustc 1.9.0-nightly ( 2016-03-07)


Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.


Doc comment says that it fails if the character is not a digit. In fact it returns option::none.


talks about what it uses to query time on the various platforms, but that is an implementation detail. The API documentation should define minimum precision guarantees for these APIs, so the user can make an informed decision whether using these APIs will provide sufficient precision for their use case on all supported platforms. For example, if a user wanted to use these APIs to limit framerate in a video game, second precision wouldn't cut it, but millisecond precision should be sufficient for most cases, so if these APIs guarantee at least millisecond precision, then they can be used for this purpose.
Should we guarantee precision or document which system APIs these things use?
I definitely agree this should be documented, at least for major platforms. If it's not documented, all you can do is test the precision, but then you have to make assumptions about future systems. If we guarantee a precision, that leaves open the question of what to do for a system that can't support such a precision. Panic?
We already can't guarantee any particular precision. Linux for example runs on processors with a wide variety of timing hardware, with all sorts of different precisions.
Perhaps we need another API to query the precision.
If it's not possible to provide any guarantees, we should at least document the precision for major (tier-1) platforms, and explicitly state that there are no guarantees for other platforms.
Does "tier-1 platform" include guest Linux on VMWare? Its clock is known to be freaky. POSIX has which return the (finest) unit of time supported by the system, but they don't guarantee measurements are that accurate. When OSs don't guarantee anything, what can Rust do? Perhaps we can just add a wrapper of these query APIs if that is convenient to somebody.
Hrrm. If truly nothing else can be done, then at least let's document the platform APIs we use for at least the major platforms, so the user doesn't have to look them up in the RFCs. That's at least more information about the precision than nothing at all.
Do we aim for at least some level of precision where possible? <sWhat is the purpose of ? Does it aim to be suitable for any kind of use? Obviously, if it doesn't aim to be useful for anything, then it's useless.</sWell, the documentation does say it's "often useful for tasks such as measuring benchmarks or timing how long an operation takes". I guess that's something.
We aim for the highest precision available on whatever platform you're running on.
Then we could put that into the documentation. That's useful information.
I tried adding etc to libstd, only to find out the libc crate lacks ...
Triage: no changes I'm aware of.
I see that you mentioned this issue in your PR! You're still interested in picking this up?
Does the Library Team want to establish a minimum guaranteed precision for std::time APIs? Or desires to have platform-specific API calls being mentioned? Otherwise we can close this issue! I personally think that listing platform-specific APIs is not a good idea since they might change over time and are a hassle to maintain for the docs-team. I don't really think a minimum precision is required either, but can be if desired. Ps. Right now I pinged everyone of the libs team (I heard team pings don't work anymore), is there any convention to follow when wanting to get in contact with the libs team on a certain issue?
I think at the bare minimum precision with respect to reading time from the system should probably documented (or rather I don't think anyone would object to that). For example Windows you get something like 10ns precision between taking timing samples whereas on Linux it's 1ns (IIRC). The precision of will always be to the nanosecond. I think one of the main remaining questions is what the precision of is. Currently has a platform-specific representation which means that it has different precisions on different platforms, but this has been considered a bug before by a few issues here and there. I do not think we should document and/or try to guarantee the precision of while we're figuring out these bugs. We don't want the documentation to tie our hands one way or another.
Thanks for your response! So if I understood you correctly the task for this issue is: Figure out the underlying API calls for and documenting the precision for each platform. Do I understand this correctly? I am currently abroad, but I can probably create a PR for this once I get home. I see that the current page already states that it operates on nanosecond precision, so we don't have to change it's documentation.
I believe so, yes. As usual though the documentation needs to be careful to indicate what's captured in this thread about how we call some APIs, but those APIs aren't guaranteed to be called. Additionally system configuration may mean the API calls are less precise. (etc, etc)


Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc


The Unix implementation of in boils down to: The branch of the conditional doesn't properly handle the case where fails. For comparison's sake, the Windows implementation says:
Oh dear, seems bad! Out of curiosity, was this discovered from reading or from a bug? We could consider a backport to beta if that's necessary
This was discovered when reading through to write a custom memory allocator for Firefox. I suspect it's hard to make it trigger due to overcommit policies and the general lack of usage of over-aligned types.


Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .


Should it expect a ? Full example code:
It should expect , but it's lost from the expected set. I't not an issue specific for , but a symptom of a more general problem with expected token sets. There's a long weekend ahead, I'll investigate.
Oh wait, this works on nightly, as expected (fixed in , more specifically). It means there are no problems with expected token sets.


Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.


The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.


This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"


Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.


It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.


From: src/test/compile- Error E0165 needs a span_label, updating it from: To:


From: src/test/compile- E0263 needs a span_label, updating it from: To: Bonus: underline and label the previous declaration:
I'm on it.


A localized (e.g. German) MSVC can produce non-UTF-8 output, which can become almost unreadable in the way it's currently forwarded to the user. This can be seen in an (otherwise unrelated) issue comment: Note especially this line: That output might be a lot longer for multiple LNK errors (one line per error, but the lines are not properly separated in the output, because they are converted to ) and become really hard to read. If possible, the output should be converted to Unicode in this case. (previously reported as ) NOTE from Please install Visual Studio English Language Pack side by side with your favorite language pack for UI
I’m surprised we try to interpret any output in Windows as UTF-8 as opposed to UTF-16, like we should.
I suspect that the MSVC compiler's raw output is encoded as Windows-1252 or Windows-1250 (for German) depending on the current console code page and not as UTF-16. Does solve the encoding problem?
No, neither in nor in (usually I'm working with the latter). It prints but the encoding problems persist.
Is it just MSVC which is localized, or is your system codepage itself different? If we know that a certain program's output is the system codepage we could use with to convert it. Perhaps we could check whether the output is UTF-8, and attempt to do the codepage conversion if it isn't.
I am using a German localized Windows. How can I find out the system codepage? The default CP for console windows is "850 (OEM - Multilingual Lateinisch I)".
You can call  with or .
That returns codepage numbers 1252 for and 850 for .
In which case the output from the linker appears to be , so now someone just has to add code to rustc which detects when the linker output isn't utf-8 on windows and use with instead.
I ran into this problem as well (also on a German Windows 10). As a workaround it helps if you go to in Win 10 to Settings -Region and Language -Language and add English as a language and make it default ( you may have to log out and back in again). After that, programs like should output using a locale that works with rust as it is right now. It would still be great if this could be fixed in rust :)
Just saw another instance of this in , except with ) (a common encoding in China), where got printed instead of the desired .
Using nightly 2019-07-04, we can confirm that this issue is fixed. (I'm using Chinese version of Visual Studio).
For me, it still does not work even with nightly build (1.38 x86_64-pc-windows-msvc, Russian version of VS). I try to compile a Hello world project in Intellij Idea but always get the exception:
Could you execute and see what that outputs?
That's a little strange. Could you open "x64 Native Tools Command Prompt for Visual Studio 2019" from start menu, and execute the following command: And see whether the output is English? If the output's still not in English, would you mind open "Visual Studio Installer" from start menu, choose "Modify" for the corresponding Visual Studio edition, and in the Language packs tab, install the English language pack. And try the instructions above again?
thanks! The hint about installing the English language pack has made the previous error disappear. But now I have another message while running in Idea: I haven't changed the path to the std library, it's looks like
Yes, this is the same error as before, it's because you didn't install windows sdk. Choose the newest one in the visual studio installer too.
thank you again. Now it's compiling and running. I'm happy ;) Just out of curiosity: was I supposed to know in advance that I would need an English lang pack and a Windows SDK when installing Visual Studio?
Please feel free to point out places where Rust tells you to install Visual Studio but does not tell you to install the Windows SDK, so that we can fix those places. It might still be worth implementing the text encoding version of the fix for people who don't have the English language pack, though I really wish we could just get unicode output out of VS without having to specify a language.
sorry, seems I was a bit inattentive. Now I double-checked: after starting rustup- the screen info says, I should assure that I have Windows SDK installed. So my fault, nothing to fix there :) Thanks.
This is not a fix anymore.
refer to
Please make sure you have installed Visual Studio English Language Pack side by side with your favorite language pack for UI for this to work.
I'm not sure this problem is really fixed. The PR that closed this kinda works around the issue because English is usually ASCII which is the same in UTF-8. However, as noted above, this relies on the Visual Studio English language pack being installed which it isn't always. And that there's no non-ascii output (e.g. file paths, etc). The suggestion to use with seems like a better fix, imho.


Full code: Given a smart pointer, which only works on types implementing the trait or on trait objects, such that is allowed to coerce to , and the corresponding implementation : Applying the operator on two will try to coerce them to , even though this isn't needed. This is an issue since coercion moves the original pointer. Removing the implementation lets the code build, which means that the coercion is not needed. As , if the is restricted to pointers with identical types (), then no coercion occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Seems related to
I've discovered a simpler reproduction: Curiously, when you just do , there's no problem. The overeager coercion can only occur in the presence of type inference. It also only occurs when the is non-parametric, i.e. not written like this: Likely because this allows to coerce to itself, hiding the issue. This also explains why it hasn't come up in the stdlib, because no type tries to coerce to a specific unsized type; it's all parametric.
The original code compiles with no errors today, so seems like E-needstest.
I think I tested the wrong thing; not E-needstest.
The linked reproduction from no longer fails to compile; is this fixed?
This is fixed but does need a test, though I think it could also be closed without a test, since it's been open for so long there's probably already coverage :thinking:
I think we should add the test just to be sure.
claim


From: src/test/compile- E0516 needs a span_label, updating it from: To:


From: src/test/compile- E0517 needs a span_label, updating it from: To: Note: you'll have to change the label to match title. There are a few different error examples in that file.


I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .


When I configured with and ran , my install ended up in .
Seems to be because of which was apparently for . If the cannot be removed, then converting to absolute path before installing might work.
I think this is still an issue with rustbuild, but should be somewhat easy to fix.. I think we just want to call canonicalize on the paths here: Does that sound correct to you? If so, this is E-easy and E-mentor (by me).
I believe so!
I can take a crack at this one if nobody else has started on it yet.
Go ahead! Let us know if there's anything we can do to help you.
Just an update - still working on this, just got buried in a move. Will try to get it knocked out this week.
are there any unit-like tests that run against the install scripts? or do they just get tested as part of the full build?
No unfortunately I don't think we test this step at all on CI :(
canonicalizing the prefix breaks when prefix is a symbolic link. e.g., /usr/local -/some/other/location Now if you want to install to <destdir/usr/local, everything goes to <destdir/some/other/location instead with many files including references to /some/other/location internally. Now when I want to change the /usr/local sym link (in my case, the underlying location is a shared NFS mount point) to point to /a/different/location that contains the rust install, all the references to /some/other/location are wrong - leaving the best remaining option to recompile rust (and that's painful) on each occurrence where the underlying path pointed to by <prefixis different. There must be a better way to solve the relative path issue than by manually converting all sym links to their resolved paths. I can't think of any packages right now where defining prefix to a sym link breaks in this way.


Here's an example:
I'm going to vote for this to be a 0.4 blocker since it's breaking cargos like . Cargo is violating an assumption in the parser that there's only one parser made per task. calls , which caches an interner in TLS on the first call, or assert if an interner has already been created. Unfortunately cargo creates a new parser session per crate, which triggers the assertion. I think this won't be too hard to work around. We could just get rid of the assertion, and share the interner across all parsers in the same thread. I'll prep a patch for this. I'm not sure if this will violate other assumptions in the compiler though. The other option would be to hack up cargo to run in a new thread. This will require some jury rigging, but it'll keep us from having to tweak the parser this close to release.
-- is this bug fixed now that your interner cache fix is merged?
yep, closing.


Currently, llvm is built with all the possible targets including Mips, ARM... For development, we can speed the build by enabling only the native target (x86 or x86_64). Maybe it would also speed the build of rustc?
FWIW, for development I use ccache (pass to ) and building LLVM takes one minute or less on a "fresh" bootstrap. (I usually work with several branches at the same time; one docker container per branch and all of them reuse the same ccache directory) Just please don't change the defaullt. I'd be very upset if I spent several minutes building stage1 rustc just to learn that it can't cross compile anything.
yeah, of course.
This is such a niche use case, to the point that it's arguably already moot by use of , if the sole purpose is to reduce build time. However there may be some other advantages, maybe space savings for use on some really storage-constrained systems? I don't know, it's trivial to make the list of targets configurable but the maintenance and support burden is real. What do the Rust team think? cc
Seems fine to me to add an option for this! We won't do it on the bots, but that doesn't mean it can't exist.


When building the following code: returns the following error message, which actually indicates the error, but also has a internal compiler error: My output:
Duplicate of , fixed in


in a file's directory to indicate that the file has unsaved changes. When for features, the rustc development tool will fail if such a lockfile exists in the source tree, with (this part being the actual bug, being that a dirty tree should fail ) a message that doesn't make it clear what happened: (The novice compiler developer wonders: what file?) I think this is likely too obscure to be worth doing anything about, but somehow managed to fall slightly over my subjective threshold of "worth filing an Issue for"; sorry if I'm miscalibrated in this matter.
It looks like the has a two parameter case for reporting path errors, which means it could be fixed by just using
Yes, that's a bit better; thanks! :sparkling_heart: (trivial PR to follow)


It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.


See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:


failure: Needs some retries here as well cc https://travis-
I'm also seeing problems when resolving with what I assume is my ISP's DNS server, but little to no problems resolving with Google's 8.8.8.8 DNS. Maybe we could configure Travis to use that? This could be (and I assume it is) a temporary malfunction.
We also should NOT be hitting the netbsd’s poor ftp server with every single build for 50MB of data.


Will find more multithreading problems.
Nominating for maturity milestone 4, "well-covered".
accepted for well-covered milestone
triage bump
visiting for triage, email from 2013-09-02. Nothing to add.
--fair-sched is new in Valgrind 3.8.0, but Rust now requires Valgrind 3.8.0 for jemalloc anyway (). It also needs platform support, but while --fair-sched=yes will terminate with an error when there is no platform support, --fair-sched=try will fallback. I think we can try this now.
assigning P-low.
Triage: Given sanxiyn's comment, could implement, but not sure where a fix for this goes.


iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.


Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)


Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.


see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik


Tracking issue for the conversion feature, by PR . The main topic during the PR's thread has been about how to handle signaling NaNs, and the final decision was to silently mask them, especially as LLVM behaviour regarding them is not well specified. Another issue by was that sNaNs are not encoded consistently. IEEE 754-2008 (section 8.2.1 in the ) specifies quiet NaNs to have their first bit of the trailing significand field set to 1, for signaling NaNs it should be set to 0. Some MIPS based platforms have it reversed. Should they be cfg'd out?
Hmm, seems this feature has broken the crate: Apparently you can't shadow functions with a trait: (the first assert works, but the second fails)
Is the issue above something we have to fix, or rather something the crate has to?
RFC 1105 laid out that so it's up to the team(s) to decide whether we're okay with the practical impact of the change.
cc --- with this merged, could we get this feature stabilized in Rust 1.20?
has been submitted to stabilize this. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] 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.
reviewed
: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.
The final comment period is now complete.
Really late to this party. As I note , the NaN masking is unnecessary from LLVM's perspective. I'm not totally clear on the platform-specific-NaN-reprs issue, but at least on x86/x64, we can just make into transmute safely. (probably also aarch64? At least its SIMD units are IEEE 754-2008 compliant, which specs NaN repr). The documentation has been written sufficiently vaguely to allow us to change the implementation to a transmute. If we wish to do so, this just leaves the following question: do we ignore the existence of non-2008-compliant hardware (transmute on all platforms) or do we allow behaviour to be platform-specific (transmute only on definitely-2008-compliant hardware)?
I'm certainly on board with just transmuting on architectures we know are okay.
Transmuting should be safe on ARM & AArch64. The only issue is whether a sNaN can cause a trap when it is used. By default floating-point exception are masked on ARM/AArch64, but can be enabled by setting some bits in the / register. These bits also allow enabling exceptions for situations like inexact floating-point rounding, float division by zero, etc. These operations are all supported in safe Rust, so I suggest that the official Rust policy be something along the lines: "Rust assumes that all floating-point operations do not trap."
I don't think we really care if the operation traps, right? It's not unsafe to do so.
We do care if the trap is considered an "observable side-effect" of the operation, since this affects optimization. This would impact dead code elimination for example: you would still have to trigger the trap even if the result of the operation is not used.
Ah sure that makes sense.
very interesting! We need more people like you :). I am personally okay with anything (the documentation was made vague purposefully!), but before we commit to anything that we can't reverse (e.g. making docs super clear that it is only a transmute), I'd love to get 's LLVM patch merged upstream so that it has been reviewed by LLVM reviewers and deemed okay.
Unfortunately, it is still necessary from LLVM's perspective; see for example. I support changing LLVM's behavior here, but this isn't just a case of fixing mistaken documentation; it's changing the policy, so we need to be careful.
Interesting. That transformation is justified by sNaN being bad, but in fact doesn't look for sNaN. Rather it looks for undef, and up to this point we've fairly conservatively considered doing ~anything with undef to be UB for Rust (because undef is poorly defined and we don't want to couple with LLVM semantics anyway). As such, the existence of that transformation shouldn't actually be a barrier to us making this change? (we should still fix llvm as well)
FWIW, that change originally came from here:
That's a good point. Allowing Rust to produce sNaNs in more places doesn't break those kinds of optimizations. And I'm not aware of any optimizations that explicitly check for sNaNs, and I've checked all the usual suspects. So this change seems ok.
cc


seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)


Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view! I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!


Specifically, there are snakecase names that cannot be converted into CamelCase (as interpreted by this lint) without losing semantics: anything that contains two numbers with a separator. E.g does not have a CamelCase equivalent that's accepted by the lint but is not confusable with the conversion result of . Originally discovered in


Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.


landed implementations for a number of derived types in collections, but imposes overly strict requirements. For example, for : Given that only the keys are printed, we should only require , not also (unless I'm mistaken?).
Yep, seems overly restrictive.
While we're on it, should only require , and the same change should be applied to and friends.


Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.


I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:


Attempting to compile this example program using a nightly compiler: On a native mips big endian machine gives me this: If I compile to an object and dump the symbols, I see that the hash for is different between the object and the rlib file: After some debugging, I managed to work out that the value of for passed to the in is byteswapped when run natively compared to running on an x86 -mips cross compiler. I couldn't work out where this value originally comes from, but hopefully someone here knows. :) I also tried using a stable compiler, but it failed with the issue before getting to this stage.
cc
I don't have a MIPS machine right here, but it certainly looks that should be returning a , which should be endianness-correct (i.e. return the same 2 u64s) -
Does beta work, btw?
It looks like affects beta as well. I get the same error as on stable - this is with:


Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!


Tracking issue for the lib feature for the column info API in the panic location hook mechanism, in PR .


Test case: With rustc 1.20.0-nightly ( 2017-07-06), output when compiling with : correctly stops the dead code / unused type alias warning from being shown, but the trait bounds not enforced warning is shown anyway. Per and , this might be on purpose. I think this is the wrong decision. The point of is to allow Cargo to inhibit warnings in external dependencies. When building Servo it is not useful to spam the console with many warnings, future-proofing or not, about code that Servo has not direct control over. CC
Nominating for discussion. Not sure if compiler team or lang team is best, though, so tagging both...
From the lang team's point of view: definitely a bug.
Couple of bugs here: First off, we should not be ignoring the bounds in types. And sometimes they are needed. I'd like to fix this by not ignoring them, but I worry about the backcompat issues. Unknown risk there. Second, if we must warn, we should be emitting a regular lint that can be silenced. Plausibly, we should just remove the warning (eliminating the immediate problem), and prioritize trying to do a proper fix here.
Somewhat related to not ignoring bounds (but in the other direction): .
After some discussion in compiler team, decided to move this to a "future compatibility" lint, one that we will hopefully make more precise over time. Right now the check is not very good. At least this means you won't have to see it. We need some mentoring instructions though!
Some tips here:
triage: P-medium
I've hit this recently. It seems like it is possible to write code that requires exactly this bound. So it is quite bad that we cannot suppress this warning. Example code:
Agreed, this is poor. There just hasn't been a lot of energy to try and improve the situation.
Fixed in , probably by We should add a regression test for this particular case before we close this issue however, since I don't think the test in the PR detects a regression for the problem described in this issue. The problem in this issue is output on stderr, not that compilation fails ( exit code is 0 both with and without the fix in the PR). label E-needs-test


Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.


This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .


The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.


Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…


"Cousins" of borrowed union sub-fields (and their further children) are not marked as borrowed.
This is , though I sort of thought we had tried to fix this.
I'm tagging this as WG-compiler-nll; I think it's something we should fix there.
For the sake of potential testsuite additions: this also should not compile with a simultaneous borrow of and .
I'll take a look at this one.
I'm not really sure what the bug is here, but I can explain what I think should be happening. This function: is responsible for determining when two values overlap. I expect us to say that two fields from a union are always considered to potentially overlap. In this case, and would be considered to overlap. Specifically, comparing those two fields would return : This is the code that I think should be responsible for doing that: It already looks a little fishy to me; in particular, it is returning if is a union, but I guess it should be equally true if is a union. Anyway, something here seems to be going awry!
So it seems like I forgot about how smart the compiler is now. This version of the test does error, as expected:
I think the policy is that we will keep this bug open, but file it under
(Since it is only fixed when NLL is enabled)
should this be ?
Note that to get an NLL test failure, you have to use after declaring :
NLL (migrate mode) is enabled in all editions as of PR . The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.


generates different HTML under and not. Not only does this trigger what's effectively a spurious warning, but it doesn't render correctly either. cc , marking this as p-high
This was fixed by google/pulldown-cmark rustdoc just needs to update its version of pulldown-cmark.
The thread in that issue says it was released in 0.0.15. we're pulling in 0.0.14 for rustdoc, but also 0.1.0 for mdbook. I'll see if i can update the dependency for rustdoc and pull it in.
updates Pulldown for rustdoc and fixes this.
I am not sure this actually fixes the warnings, as they use different IDs and such. I'm testing this locally right now though; expect an update in ~20 minutes


Hey, I'm curious about the . From what I understand: this works because Path is a single member struct containing only the type it's being reinterpreted as. My original question on #rust IRC was: Is this always guaranteed to be correct (in Rust) in terms of memory layout? The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs. I would love some clarification if this usage is correct or to what degree it is not. I'd also suggest we add clarification around this case with comments or support functions to aid future spelunking into std.
No, strictly speaking, this is not safe without .
excellent, thank you! The seems to indicate things going slowly. Adding a comment might still be a good idea for now. Reading the RFC, it mentions at least ARM64 where there might be layout differences. But according to , std shows up as supported as a Tier 2 platform. This implies that at least for now, this pattern in this instance () works. Is this correct?
That ARM64 issue seems to be related to calling convention, not memory layout, so it's not an issue here.
This is my understanding as well. I believe it is safe with either repr(transparent) or repr(C), the latter of which is stable. The  crate is a generalization of this safe cast.


The benchmarks for LinearMap and TreeMap should just be using the Map trait, but I encountered a strange borrow checking issue: diff: error: This seems like a borrowck bug, but I'm not sure. The same issue occurs when trying to work around it with a trait like with a method.


Implemented in .
Dumping this link here for future reference:
Closing since is stable in nightly and will make its way to stable in 1.26.0.
I was confused why this was allowed to stabilize, but it appears that was fixed?
The mechanism doesn't work anymore at least. Should we escalate this to a new issue with P-high?
Nope, just leaving a historical note for anyone else who was confused. Although if anyone knows when this was fixed (and if a test was ?) that would be good to note.


Index out of bounds ICE while compiling . I don't know enough about why this could happen to produce a minimal reproduction. Backtrace:
here's a test case. i got this ICE by random (un)luck and i can't remove any further code or it won't reproduce. at least it's a single file. cannot reproduce with rustc, must be called from cargo. Cargo toml has no dependencies tho
at least i think its related, since its in CacheDecoder as well
cannot reproduce after cargo clean, so attached is the entire project. linux x86_64 rustc 1.26.2 ( 2018-06-01)


this code currently emmits Could we detect explicitly if there are 2 unchained (via && or ) "variables" after an "if" and if the first one is "not" and explicitly suggest using "!" instead of "not" instead? meta: `


This is an issue extracted from which is caused by an issue that any OSX compilation with debuginfo ends up being nondeterministic. Specifically (currently known at least) the source of nondeterminism is that an mtime for an object file winds up in the final binary. It turns out this isn't really our fault (unfortunately that makes it harder to fix!). This can be reproduced with just C and a linker: Here we're using the exact same object file (with two timestamps) and we're seeing different linked artifacts. This is a source of bugs in programs that expect rustc to be deterministic (aka as was originally stated) and is something that we as rustc should probably fix. Unfortunately I don't really know of a fix for this myself. I'd be tempted to take a big hammer to the problem and deterministically set all mtime fields for objects going into the linker to a known fixed value, but that unfortunately doesn't fix the determinism for C code (whose objects we don't control) and also is probably too big of a hammer (if a build system uses the mtime of the object to control rebuilds it'd get mixed up). We could also use something like and reach in to the specific field and remove the actual data. I found it in a symbol section with the type (described in various documents online too apparently). We may be able to postprocess all output artifacts on OSX to maybe just zero out these fields unconditionally (or set them to something like May 15, 2015), although I'm not actually sure if this would be easy to do.
cc cc (you're probably interested in this for the sccache ramifications like is)
If we used LLD for linking (), it would be possible to fix this in the linker (by providing a flag to ignore mtime). This would also fix (this part of) deterministic compilation for other languages as well.
Source code for the darwin linker , but I have no idea whether they take patches. Maybe LLVM develpers know more. Most likely, Apple will switch to LLD eventually.
I wonder what experts on deterministic builds ( ) can say about this.
Hm. I wonder why we haven't noticed this for Firefox builds? Maybe the version of the linker we're using has a patch to work around this? We're using for our builds.
that is indeed surprising! The source code there , but that may be getting postprocessed somewhere else perhaps.
We discussed this on IRC, and I suspect the reason is that nobody has actually tried to do unstripped reproducible Firefox builds for macOS (although I'm not 100% sure). The info in question are STABS entries used by dsymutil to link the debug info from the object files into the dSYM. This isn't critical for sccache currently, since it doesn't cache linker outputs.
Related: noticed that static archives are not reproducible on macOS because Apple's tool puts timestamps in the archive ().
Right, I think the impact on sccache is similar to What I am seeing is that the .dylib non-determinism is causing unexpected cache misses in sccache since the dylibs end up being passed to rustc. Here is an example for :
Ah, right, proc macro crates!
This should be fixable by setting the in the env of the linker (libtool and ld64). For more context, see determinism blog post and commit for Chromium. I'm not sure of the first Xcode version that supports this though.
It should be harmless to set it even if it's not supported, you just won't get a deterministic binary. in the most recent ld64 source available, FWIW.


If a procedural macro generates an access to a named struct field like then the may be either defsite or callsite and it works either way. But if accessing an unnamed tuple struct field like then it only works if is call_site. I believe it should work either way in either case.
Sorry for the delay! Fixed in .


I'd like to work on this.
This appears to be a regular error, not an ICE.


When building the documentation (or running the doctests) of a few crates, such as libsecp256k1, in beta or nightly, rustdoc crashes with this message (while it works fine on stable, even if with some pulldown warnings): Crate regressed from stable to beta (). Crate regressed from stable to beta (). cc
Crate is also affected, cc
Can someone investigate and see if we can fix this?
I'll give it a look.
Both and worked just fine for me...
I ran on on my own system without updating my nightly and hit the ICE:
So maybe we need a backport to beta? That may have already happened, this is a relatively old beta run.
First we'd need to find what's crashing...
I've tried bisecting in the range ... and the result is... ? Needs to reverify later. Test script: Command: Edit: Verified, in the doc test passes and in the doc test ICEs. cc
I just tried documenting with that exact nightly and it crashed for me? <details</detailsThe issue is still present on the latest nightly: <details</details
Negative, it is still crashing with . <details</details
This seems potentially somewhat suspicious from the commit we bisected to:
Here's a minimal example: We used to run everybody-loops before macro expansion. Which meant that such macros would be wiped clean (as well as all of their potential users). We now run it later. These macros get cleaned up after we've run them through resolve. This interacts badly with how we do builtin lints. Builtin lints are basically things where writing a lint pass to do the check would be annoying because it requires a global analysis, but we can instead collect up the requisite information beforehand during other global passes, and then when we are actually linting a node we can just check what lints have accumulated for that node. For example, the unused lints work by paring down a list of "used" things, and then buffering up an "unused" lint for each thing that's still unused after the resolution check. We can't warn immediately because we'd have to recompute what the lint level is. The unused macro lint is naturally a builtin lint. Macro expansion queues up a list of "this macro is unused" lints for each macro node id. Of course, with the everybody-loops pass, we delete the macros within the blocks. Whoops. And this causes the lint pass to notice that some of the accumulated builtin lints were not checked (because their nodes no longer exist), and complain and ICE. Whoops. To fix this, we can: not run early lints in rustdoc mode. Or really, any lints. Except for rustdoc-specific ones. Idk. Conditioning that invocation on rustdoc mode. Remove the invocation entirely -- whilst macros and derive can't remove nodes, proc macro attrs can. I need to check if this ICE can be triggered with a proc macro. Add complex checking that ensures that buffered lints for removed nodes stay removed I'd rather lean towards conditioning or removing that invocation
For some reason I'm not unable to get this ICE to trigger by writing a proc macro that does this. Curious. Perhaps this occurs pre-macro resolution.
Oh, I think the proc macro just "gets there first" because it's defined outside. Okay. So checking for rustdoc mode should be enough.


/ and / do the same thing.
So, should registertask/unregistertask then be exposed in rust_builtin so it can be called from Rust?
Yes, though I suggest renaming it, since it will no longer just be used for 'registering', nor does it strictly have anything to do with tasks or weak tasks from the kernel's perspective - this count is only for determining when to shutdown the runtime. Maybe for the method name and for the builtin. It's not great either, but is less wed to implementation details.


Do you have a testcase that reproduces this problem? Also, what version of rustc are you using?
I'm sorry late for your comment. $ rustc this is bad my code. : : rustc 0.6 ( 2013-01-20 20:35:24 -0800)
From my cursory glance, multibyte characters (Hangul in this case) seem to cause this bug.
Not critical for 0.6; removing milestone
Seems to be fixed. Checking in a test case.
Done pending
Test case in , closing


Would you like to fix this bug? If so, . The documentation currently states that : However, this is not what 's of that method does. It will only fill the buffer if no data is currently buffered. If data is already present in the buffer, no filling takes place: I would argue that the current behavior of 's implementation is usually what users would want to do, but if does not match the documentation of, nor the name of, . I don't know what the right solution here is, but I suspect the only safe thing to do would be to update 's implementation to match the docs (i.e., to make it actually fill its buffer), and then to add another method to (perhaps ?) that gives the currently buffered contents, regardless of the amount of buffered data, and without reading from the underlying .
Adding a method to would be a breaking change unless you have a suitable default implementation in mind. I would love it if we can make "every time this is called, the implementation should fetch more data" part of the API contract because it's easy to get burned when you make that assumption with . The only one impl I know of where this guarantee isn't really feasible is which can only return buffers from one source at a time.
Well, even that is tricky, right? What if the buffer is already full? I also think there's value in being able to get access to the bytes currently in the buffer without doing a syscall (something like ).
The issue is that you can't really do anything to the structure of the trait at this point without breaking changes, though this is now feasible with epochs. Adding extra functionality directly to is quite a bit more reasonable though. I have that I couldn't be bothered to champion and instead just .
I guess one question is where we decide to not expand and say that external crates should provide features instead. I'd advocate for this being something should support (though as you say, possibly not ).
I also ran into this 'faulty' documentation issue. I have a program which needed pushing back data on the reader and by reading the documentation I thought I could use fillbuf with consume for that, but found out the hard way that fillbuf isn't actually filling the buffer but returning the existing buffer if something is still in there. Hardly appreciated if the fill_buf acts as documented.
The proposed behavior is fundamentally broken. Imagine a being used to parse some line-oriented protocol. The BufReader's buffer capacity is 4096 bytes, and the peer sends a single TCP packet with 2 lines in 100 bytes. It then expects our end to respond, so it's not doing any more writes. You call , which calls into . Since this is a new , the buffer is empty so it calls down into the and reads all 100 bytes into the buffer. then returns the first line, and there's the one remaining line in the buffer. Now you call again to read the last line the peer sent over. With the current behavior, the 's buffer is nonempty, so immediately returns it. returns the last line our end responds to the peer, and everything is happy. With the proposed behavior, calls back down into the since its buffer isn't full and the protocol deadlocks.
Just to clarify, is the idea here to update the docs from: Fills the internal buffer of this object, returning the buffer contents. something like this?
Ah, commented while I was writing my comment and answered a couple of the questions I had
I'd probably phrase it as
I agree with you that changing the behavior of seems wrong. As pointed out in the original post: "the current behavior of 's implementation is usually what users would want to do, but if does not match the documentation of, nor the name of, ". I do think there's an argument for providing a method that gives the buffer contents without ever doing a syscall, but that's probably an argument for another issue.
I'm happy to mentor anyone who wants to fix this issue! Here's how: The line in question is here: This should be changed to: I'm happy to answer any additional questions!
Perhaps we should also include a reference to the newly ()? Though I suppose that is (sadly) only available for and not all .


This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables


Document of and for unsingned integers take 2^4 ( is not xor but power) as examples. Because 2^4 = 4^2, these examples are not very helpful for those unfamiliar with math words in English and thus rely on example codes. We should take another example, e.g. 2^5 (which is not equal to 5^2).


One of the easiest ways to make CI faster is to make things parallel and simply use the hardware we have available to us. Unfortunately though we don't have a lot of data about how parallel our build is. Are there steps we think are parallel but actually aren't? Are we pegged to one core for long durations when there's other work we could be doing? The general idea here is that we'd spin up a daemon at the very start of the build which would sample CPU utilization every so often. This daemon would then update a file that's either displayed or uploaded at the end of the build. Hopefully we could then use these logs to get a better view into how the builders are working during the build, diagnose non-parallel portions of the build, and implement fixes to use all the cpus we've got. cc
On Windows this can be done by taking advantage of job objects. If the entire build is wrapped in a job object then we can call with to get a bunch of useful data.
I made script that will print output into the travis log every 30 seconds , . Some findings: Cloning submodules jemalloc, libcompilerbuildtins and liblibc alone takes 30 seconds. While building bootstrap, compiling serdederive, serdejson and bootstrap crates seems to take 30 seconds (total build time: 47 seconds). stage0: Compiling tidy crate seems to take around 30 seconds. Compiling rustcerrors takes at least 2 minutes, only one codegen-unit is used Compiling syntaxext takes 9 minutes, only one CGU used stage0 codegen artifacts: Compiling rustcllvm takes 1,5 minutes, one CGU During stage1, rustcerrors and syntaxext builds are approximately as slow as during stage0, rustc_plugins 2 minutes, one CGU. stage2: rustdoc took 2 minutes to build, one CGU compiletest suite=run-make mode=run-make: It looks like there is a single test that takes around 3 minutes to complete and has no parallelization. Testing alloc stage1: building liballoc takes around a minute Testing syntax stage1: building syntax takes 1.5 minutes, one CGU Notes: When the load average dropped towards 1, I assumed only one codegen unit was active. The script was only applied to the default pullrequest travis-ci configuration.
As shown in , the CPUs assigned to each job may have some performance difference: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz The clock-rate 2.4 GHz vs 2.5 GHz shouldn't make any noticeable difference though (this would at most slow down by 7.2 minutes out of 3 hours if everything is CPU-bound). It is not enough to explain the timeout in .
I was working on recently for this where it periodically prints out the CPU usage as a percentage for the whole system (aka 1 core on a 4 core machine is 25%). I only got Linux/OSX working though and was unable to figure out a good way to do it on Windows. My thinking for how we'd do this is probably download a binary near the beginning of the build (or set up some script). We'd then run just before we run . That way we could correlate the two timestamps of each log (the main log and the to similar moments in time. Initially I was also thinking we'd just at the end of the build and scrape it later if need be.


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


Servo doesn’t build in today’s Nightly: Since the type is stable I think this is a breaking change. CC for
The type is stable, but that impl is . Edit: just realised that's not the impl in question, just wanted to say that I don't think it's a breaking change with regard to stable.
Oops. Indeed, that's a regression.
Egad sorry about that! I've posted to revert this change


This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?


I've just got very surprised to find out that doesn't compile, but does. After some investigation, I found that is missing. Similar impl is present for though. I believe it'd be nice to implement it.
is to as is to , so check out , this implementation might meet your needs.
I've soled my problem immediately. I filed issue because I think we could help others by implementing the trait.


These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)


Context: In order to experiment with an -aware , I was preparing to modify the lang item signature, and my first step was to ensure MIR passes the right type to begin with, as noted in Legitimately, I assumed that the MIR inline code was doing the right thing, so I mimicked it in . The resulting code actually works fine, as far as completing the 3 stages of rustc bootstrapping is involved. But before going the route for the -aware , I first tried removing the special handling of 's , trying to leave it to , shortcutting the lang item. This didn't go well, and produced a stage 1 compiler that would crash on a bad in libsyntax's . From which I derived a small test case that would exhibit the problem with my code. Anyways, I was going well over my head with this approach, thus switched to the signature change. So, what's the deal with this issue, will you ask? Well, it turns out that my MIR changes, essentially copied from MIR inlining, while they worked to produce an apparently working compiler, failed to compile that reduced testcase with an LLVM ERROR. I was wondering if I did something significantly different from what the MIT inlining pass was doing, so I tried to trigger it manually (since it's not enabled by default), and after some trial and error, got it to happen on a plain nightly compiler, with the following reduced testcase: Building with yields: (Note the is only there to force MIR inlining to happen without having to go over the required threshold ; liballoc's has ; similarly, the on avoids inlining of dealloc, to limit the effects on the MIR) Interestingly enough, and fail with the same error. The former outputs a truncated MIR (truncated at the entry of the first basic block), and the latter outputs nothing.
This is what from a run with looks like: Edit: and what the llvm-ir, as disassembled from output, looks like:
The problem is that the code path bb1-bb9-bb21-bb20 in IR, corresponding to bb0-bb1-bb6-bb5 in MIR, is impossible, yet exists. And in that code path, in MIR, in IR, is never initialized, and that's what LLVM doesn't like. I guess one way to look at is it to wonder why in MIR has a switch in the first place.
And the answer to that last question is false edges, according to the following MIR from the mir_map pass:
Actually, the path bb0-bb7-bb4-bb10-bb12 has without ever being initialized, but that's pre-elaborate-drops, and I hear drop is different then, so I don't know if it bad or not.
The weird switch that eventually causes the LLVM problem is by the elaborate-drops pass. The MIR after that phase looks like the following:
I think the most relevant fact is this difference between MIR inlining being enabled or not: with MIR inlining disabled, this basic block in MIR: becomes the following IR: with MIR inlining enabled, this basic block in MIR: becomes whiich is weird... where did the extra code go?
The changes from fix this issue.


When I run the test suite on campus, I get a failure in : The test says "this IP is unroutable, so connections should always time out," but evidently there's something about the setup at this location that was not anticipated. The results are the same whether I am connected to WiFi or through ethernet. Both connections go through the same router (a Linksys WRT120N I have physical access to, which doesn't appear to save any sort of logs), and I don't know where it goes after that. I can work around it by disconnecting from the internet entirely, and do not have issues when running the tests at home (same laptop, different network).
is your subnet 10.255.255.0/24 or 10.255.0.0/16 or 10.0.0.0/8 or anything similar? You can check by running . Either way, the test is ill formed and should be correctled.
I'm not there right now, but just in case I forget to come back to this, I do recall that the router is accessed through an IP in the 192.168.x.x subnet. (I'm not sure if this precludes the situation you have described) (I wish GitHub notifications had a "mark unread" feature!)
It appears not to be. wifi ethernet:
I think I must have misread something when making that test - the IP is inside of an address block reserved for private networks which means it could be routable depending on how your network is set up. We could instead use an IP from one of the documentation blocks like 192.0.2.0.
The address 10.255.255.1 is routable on my vanilla Ubuntu 18.04 box: The address 192.0.2.0 is not routable: Therefore, this test always fails on this box. I will file a PR changing it to 192.0.2.0.
This is a dup of .


I think this is the fourth beta I'm having to re-figure-out how all this works and figure out how to ignore their failures on beta. can we just exclude these tools from toolstate until this is figured out?
I'm slightly confused, why would these tools need to be disabled/their submodule update if they were building on master? Isn't the beta just the current master branch + some tweaks for --version output and no unstable features? The release in March actually prevented the merge of any PRs on master that would break a tool. So I thought the idea was to fix all tools in that week. Or is this about beta backports breaking tools?
I don't think we've had a beta yet whether either clippy or miri were passing tests and fails the build if any tool fails to build on beta. We also do not want to release either of these tools to stable/beta yet.
neither of these tools has a step, so there's no danger in that (the last beta) didn't have clippy issues. Since we have grace period of a week, I can easily get in a working clippy within that week (which then won't be broken until the beta). My issue is mainly that I don't really know when it begins ;) Maybe we can ping the tool authors once a day that their tool needs to be fixed for the upcoming beta?
My point with this issue is that we shouldn't automate ourselves into a hole where tools we do not want to ship block releases. That should not require authors to fix tools, we should simply ignore failures or have an easy way of disabling them. Right now producing a beta is pain as you have to resend it to bors multiple times after re-learning that these are blocking the release. We do not ship miri/clippy but a successful clippy compilation affects how rls is compiled, which should not be happening on beta/stable.
The code that influences rls is explicitly skipped on beta/stable, so the rls is completely free of clippy on beta/stable for miri I agree, but for clippy, aren't we trying to move to a model where we actually dist it on stable, so I'd call having it ready for stable some form of proof of concept for the distributing part.
Ok sure yes rls is protected but I feel like this is missing my point. Miri isn't ready. Clippy isn't ready. They're blocking beta releases. That shouldn't happen.


When testing a local rebuild in Fedora -- using rustc 1.26.0 as stage0 to build rustc 1.26.0 again -- I ran into this ICE: The "slice index starts at 1 but ends at 0" comes from here: With GDB I found that is completely empty! Stepping through from the very beginning, does get the right argc and argv, calling appropriately. But the addresses of and are not where accesses later from , so that just sees and . It turns out that the bootstrap was causing my to load the freshly-built libraries, rather than its own in . The bootstrap wrapper does try to set a libdir at the front of that path, but it uses , here , so that doesn't help. This only hits local-rebuild, because normal prior-release stage0 builds have different library metadata.
Is this fixed? cc
Sorry, yes, fixed by .


For type names only, submodules can't apparently see non-pub types defined in the parent module. So, this code: ... generates this error:
Now it at least tells you that is private: Though, it doesn't need to display the error twice and could do better than .
linking to for unified tracking of resolve
Closing as a dupe of , this would be allowed with the rules in that bug.


This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest


I've some code reading a stream from stdin. Wanted to wrap it in a Cursor to have it keep track of the number of bytes read already instead of having to do it manually, but started getting odd compiler errors. Since works just fine with (and ) shouldn't it work just the same with ? () Errors:
A Cursor is meant as a wrapper to Vec<u8or &mut [u8] to be able to write to them. The compiler error says that StdinLock cant be converted to a slice.
That's not how I understood it from the documentation. to me that suggests the main purpose is to provide Seek implementation. If it's only meant to wrap Vec or [u8] I think it would avoid misunderstandings to say so out right. Again suggesting Cursor is fairly generic about underlying I/O object. (FWIW if asked to name some I/O objects, I'd be pressed to consider Vec and [u8] as such.) ... The compiler error is confusing as at no point is there any (obvious) attempt to convert StdinLock into a slice. It's only ever used through the Read trait. Though looking more closely I now see the fine print later on () so I guess one could argue this is just a minor documentation issue (+ user error.) I'd still argue the behavior is surprising. StdinLock implements Read, so does Cursor, there's no obvious reason why Cursor<StdinLockwouldn't. I can sort of understand why it's currently that way, and can imagine some problems there may be generalizing it, but can't quite see any fundamental reasons for Cursor to be restricted to only Vec and [u8] and the documentation is vague enough to make that seem like a bug / unintended omission rather than intentional design / limitation.
It is a docs bug. The entire purpose of Cursor is to take a buffer of bytes and turn that into a reader by adding a cursor indicating the current position in the buffer.
Made a PR to suggest some documentation changes to better describe the intention. I do wonder though if the guard should also be included for , it could capture the problem more accurately where it's happening?
There probably should have been an bound on , but we can't add it now.


Reproduced on versions: - Isolated example to reproduce: Actual error: Mentioned suggestion about "wrap into " is incorrect at all. There we should deref the value from the . - - Expected error: (something like this)
Here's where the suggestion gets issued: The motivation was to solve (where a -expression appears in tail position, which seemed likely to be a common mistake), but it turns out that there are other situations where we run into a type mismatch between match arms of a desugared expression. We regret the error.
Here's another case of this:
I see what's happening, we're only checking wether the error came from a desugaring, disregarding the types involved. It should be possible to check that information as well, even if the suggestion is only provided when it's a where everything but the error type matches. (I think it's ok if the supplied error cannot be converted to the expected error, as this suggestion exposes newcomers to a non-obvious construct at least.)
Clippy to detect this that we might want to uplift ...
(But for now I'm just going to remove the suggestion.)


What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up. I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim


LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.