RFC: RFC PR: Todo: [x] Land [x] Make it work with cross-crate imports (, ) [x] Make it work for proc macros [x] Make it warn more on resolution errors () [x] Make warnings/errors use better spans than the first line of docs [x] first step: attribute () [x] point to actual link in doc comment () [x] Add lint for link resolution failure () [x] Implied Shortcut Reference Links () [x] blocked on and [x] Enum variants and UFCS/associated methods () [x] Primitives () [x] Use the right resolution scopes for inner doc comments on things that aren't modules () [x] Handle fields and variants () [x] Handle fields inside struct variants () [x] Support () [x] Write documentation () [x] Stabilization ( - current impl is gated to only run on nightly, but does not require a feature gate) [x] Handle methods from traits implementations [x] Support anchors () [x] Support missing primitive types (such as slices) () [x] Allow referring to (for on ) [x] Fix current crate linking when no module is provided in the path (for example, won't link to the crate's type for some reason) [x] reexports can break intra-doc links () [x] Support associated items in contexts other than documenting a trait method () Other related issues: [x] Suppress privacy errors with document-private-types (, fix at ) [x] provide option to turn intra-link resolution errors into proper errors ()
Preliminary implementation notes: Getting just the links from the markdown is relatively straightforward. You'll need to do this twice, to capture the behavior in both the Hoedown and Pulldown markdown renderers. Thankfully, each has a way of capturing links as they are parsed from the document. (While capturing the link you can also look for the "struct/enum/mod/macro/static/etc" marker to aid in resolution down the line.) In Hoedown, the function in captures all the events as they are captured. Hoedown uses a system of registering callbacks on the renderer configuration to capture each event separately. The event and its related function pointer signature are already present in the file, so you would need to create and use that callback to capture and modify links as they appear. For Pulldown, the parser is surfaced as an of events. There are already a handful of iterator wrappers present in , so adding another one (and using it in the farther down) shouldn't be a big deal. I'm... honestly not that familiar with how Pulldown represents link definitions in its Event/Tag enums, so more research would be needed to effectively get link text for that. Now, with the links in hand, you need to do two things, neither of which i know offhand since they involve interfacing with the compiler: Attempt to parse the link as a path (if it's not a valid Rust path, just emit the URL as-is and skip the rest of this) Resolve the path in the "current" module (emit a warning if resolution fails) Presumably there's a way to make the resolution come up with a DefId? Even after cleaning the AST, rustdoc still deals in those, so if that's the case there are ways to map that to the proper relative link.
I've got a WIP going on in , which works off of Misdreavus' WIP (they did most of the work).
Note that that branch is now live as , which i'm polishing and finishing up.
Note for people watching this thread but not We're trying to wind that PR down to get a minimal version landed, so an initial implementation is fairly close.
One thing that appears to not work in (and I don't think is ever explicitly addressed in the RFC) is how to link to primitives like or .
Yeah I have to investigate that
should we turn the error into a warning ? I don't like the idea of crate docs breaking because someone introduced a name into a glob import
does rustdoc have some idea of "lint levels"? What are the current deprecation warnings? Just println!s?
We can just instead. rustc can emit warnings not tied to actual warning names. There are no lint levels.
Alright, let's do that for now. In the end I'd really like to have a way to check the docs for errors but that's a more involved/fragile process I imagine. Manish Goregaokar < am Mi. 24. Jan. 2018 um 09:17:
Shortcut links being implemented at
If will work as part of this RFC, will also work for linking to specific sections of that documentation?
Not currently. This can be implemented. ९ मार्च, २०१८ २:१४ म.उ. रोजी, "Sunjay Varma" <notifications लिहिले:
I can't seem to get links to struct fields to work (either or ). Am I missing something, or is it not implemented? If not, is it planned to be supported?
should work
Oh, wait, no, struct fields don't work yet. We can add those later.
Was their any discussion about linking to dev-dependencies? For example in a heavy crate like it may be that some sub-crates want to link back to the prelude at directly. One way this could be done is simply including dev-dependencies in the doc build and relying on the implicit use of crates in Edition 2018.
Edge-case error I found: apparently, if a crate is marked as , then this also applies to autolinks; I can't link in a crate even if the crate itself doesn't need it. This seems like a relatively easy bug to fix imho.
Based on a conversation just now: It would be cool if we could add in a section to pages to collect "back-links", or a listing of pages that contain doc-links to a given page.
One thing I would really love was if in the documentation for some type linked to automatically. It makes it a little easier to write documentation text that flows nicely and doesn't seem awkward (I know you're talking about a method on , that's the text I'm reading!)
That would be ambiguous though, if a top level item existed with the same name. I would personally be happy if [Self::method] worked.
Maybe works today? (As in, .) We could establish a priority to resolve ambiguities.
is nice, though I would want it to be rendered as just . This shows up a lot in documentation of the form: If these cases, and would seem a bit redundant, and make the sentence harder to follow.
I think it should be fine if it was written as , as it is unambiguous, but rustdoc would recognize that it's a method, and rendered it as just . If the user really wanted to keep the part in the rendered version for some reason, they could just write . EDIT: Jeezus, I was on phone, and couldn't find the backtick on the virtual keyboard.
In the futures crate we get a lot of intra doc resolution warnings. The curious thing is that these warnings are always for another crate than the crate for which the docs are currently being built. E.g. on its own builds with no warnings. However, , which depends on , builds with warnings from . https://travis-
Should "point to actual link in doc comment" be checked off since is merged?
Also "Add lint for link resolution failure" ()
And looks like "Support Self" was in .
Checked the 3 of them.
I'm finding a resolution failure that is puzzling me: Neither nor resolve.
It makes sense to me that bazFoo::bazusestatement) so that seems fine to me. That doesn't resolve either seems odd. Does resolution work when written on associated methods?
doesn't resolve the same way IIRC, so we'd have to explicitly support it
As said.
This is only tangentially related, but is there any way at all we could help improve the situation for 's that are generated from rustdoc with this change? I'm thinking specifically of , though I'm sure there are other cases where the relative links won't resolve. Could we generate absolute links instead based on the key in (if present)?
Here's another interesting issue: If you take the module docs in and remove the Rcstd is organized. Does this have to do with the cross-crate imports bullet point above?
When building docs with deny warnings on nightly, currently you get a bunch of errors related to intra rustdoc links not being resolvable. It looks like the errors are coming from building docs for the standard library itself. Can we add something to the Rust CI to check for these warnings, or otherwise disable issuing these warnings when building downstream crates? Example: <details<p</p</details
I was actually putting together a PR to deny the warnings, but it appears that some of the existing failures are caused by issues in the implementation rather than errors in the documentation. So, like you said, it might be best to silence them when documenting downstream crates for now.
I assume that "Make it work with cross-crate imports" in the OP is referring to things like docs on externally-defined trait implementations failing to resolve and causing warnings to appear, even though the docs are valid in the crate that defined the trait? Is this still blocked on something else (and if so, is there somewhere with more details for tracking it than a comment on the old PR)?
The issue is hitting in is still happening and is a serious blocker for me-- even when building with --no-deps, I'm getting warnings and errors from upstream documentation resolution failures.
(am unblocked through the magic of RUSTDOC env var, shell scripts, and the --cap-lints setting, but still this should get fixed XD)
This is enough to trigger a failure right now. (I'll need to narrow it down, but using a crate with some specific use of intra-links will work.) I thought i'd fixed this kind of erroneous error with but it turns out it wasn't good enough. I'm building/testing a fix right now that refuses to run link collection on non-local items. It may be a bit drastic (and breaks docs which actually work in this situation) but it finally silence this kind of issue until we can actually support them.
Narrowed it down: I bet the PR i linked doesn't touch this impl because it's generic, so it could apply to any number of local items.
In Rocket, we have two libraries in a workspace: a core library, , and a contrib library . is not a dependency of , but refers to in its documentation often. Because is not a dependency of , cross-crate links are not resolving: Is there any workaround to this? I've tried adding manually via , as well as using , but neither work. Even if the latter worked, it isn't a great solution as it'll produce absolute links, partially defeating the purpose. In general, I think and/or should automatically add all crates in the same workspace to the resolution domain for inter-crate links, making something like work out of the box.
have you tried adding a feature to the lib that you set when building docs and that enables an optional dependency on ? (Sorry to respond here without having followed this issue or impl much!)
This will cause issues with the docs when built outside the workspace, e.g. when someone runs to get locally built docs in their project. Changing or having an optional feature has similar problems. I suggested including during doc builds to solve the same issue, or maybe there could be an additional section?
I considered that, but unfortunately that would introduce a cyclic dependency. I instinctively tried that - placing the dependency in - actually. Although I secretly hoped it didn't work as I really don't want to build/check when working on . A special section would resolve this particular issue if it allowed cyclic dependencies.
Currently it's possible to link to fields of structs via a form of psuedo-path: Similarly it would be useful if it were possible to link to fields of a variant of an enum, probably via the same sort of psuedo-path:
I'm trying to ascertain the readiness of this feature for release use, and was hoping the tracking issue might help. While it is working great for me on recent nightly builds, on the just released stable rust 1.30.0 ( 2018-10-24), I'm surprised to find that the feature still isn't complete: some links using rust paths aren't resolved to html links. Is this feature intended to be nightly only? Or is there flags or feature's to be set in order to use it with the rust stable channel? Should I file a new issue for the missed links on 1.30?
There's a big hole in the current implementation, documentation for re-exported items doesn't work. Re-exports are used a lot in the ecosystem so this is a stabilization blocker. It's nontrivial to implement since it requires some architectural changes. Also, yeah, file issues for missing links, cc me. On Thu, Oct 25, 2018, 6:12 PM David Kellum <:
I'm not privy to how Rust tends to handle these sorts of things, so I realize this might go against established practice, but it seems to me like it would be useful to have what currently exists in stable, but just not promoted as something that actually works. It's not dangerous and is useful in its current state. I guess the risk is that nobody ever finishes the support for re-exports and we're stuck with a half working feature?
The problem is more that the brokenness of re-exports is subtle. If folks start using this in documentation, they may not notice that it's broken in re-exports, which will end up showing ugly documentation. I'm not going to push back strongly though, if the docs team feels that early stabilization is okay that sounds good to me. On Thu, Oct 25, 2018, 6:37 PM Peter Wagenet <:
I've found it super useful in its current form, but I can see the worry around things being subtly broken.
I misinterpreted what I was initially seeing on 1.30: all, not just some, rust path style links (this feature) are not resolved on this latest (and prior) stable releases. Besides that not being explained anywhere I can find, the output is slightly confusing because the implicit type links are shown as obviously broken, e.g. "[]" where as links explicitly using a rust path are included verbatim, e.g. , as would be expected without this feature being present. As it seems now the intent for this was to be nightly-only until further along, shouldn't this tracking issue be edited to include the following, as it might save the next prospective user some confusion ( [ ] Stabilization PR (current implementation is nightly only, but not feature gated) I agree that this is value add as found on current nightly. Authors can just avoid using the new link style for re-exports, as well as links to other crates which are not dependencies, until these are resolved. But as it stands, its a bit difficult to justify using the feature when it will not generate correct links for a user-local even on the latest stable, not to mention the minimum stable rust version. Please consider if keeping this off for stable, with no option or flag, is now more likely to cause trouble with broken links (as this starts getting used with nightly) vs any regressions stabilizing might otherwise cause, given that the new style link targets would never have worked without the feature?
Random idea: If it is planned to keep this semi-usable for a few more months, it might interesting to see if we can make nightly rustdoc optionally print out the generated relative links (with obvious issues when docs are rendered in more than one place). I don't think we have precendence for this, but if you someone wants to have a fun project, they might even try to integrate this with rustfix (i.e., yield 'suggestion-like' output where you appen for each link).  You can use it right now, with the obvious missing features mentioned above. Since uses a nightly compiler version where the intra doc links work, a lot of people reading the docs for your crate will see the correct links. People trying to build the docs will be disappointed, though.
You are correct in your observations: The feature is currently written so that links will only ever resolve when running on a nightly (or locally-compiled) rustdoc. In any other situation, they will be passed through in the way you observed. The current implementation of intra-doc links is not only incomplete, as mentioned, but is also bug-ridden: There have long been issues of spurious "dead links" being found in crates which aren't using intra-doc links at all. This, combined with the fact that we emit a proper warning lint for these resolution errors, led to situations where innocent crates suddenly broke because they had set. To be honest, running this without a proper feature gate is shaky, in terms of how unstable features work in the rest of the compiler and rustdoc, but until recently i was uncertain if we could properly introduce a gate to the compiler without a matching use in rustc itself. (All the attributes that rustdoc currently uses are tied to attributes, so their check code is also in the compiler.) I would be willing to introduce a feature gate for this, since it would also stamp down on the false positive rate across the ecosystem. However, it leads to similar broken-link situations. Imagine crate A which uses intra-doc links, complete with having the feature set. Now imagine crate B, which re-exports items from crate A to inline them into its own documentation, but doesn't use intra-doc links itself. Because crate B doesn't have the feature set, now those links from the crate A items won't resolve, even if they were accidentally correct because those items were re-exported into the right positions! (This situation exists today; these crates are and , though the items from that re-exports don't have any links on them.) I'm very hesitant to "partially stabilize" these links, because of the subtleties with re-exports that mentioned. It's too easy to use any part of this feature and get it to a position where it doesn't work. And the major hurdle for making that work requires a deep compiler refactor that is hard to find a champion for. If it comes down to it, if there is another Rust All-Hands early next year like the one in Berlin earlier this year, i may try getting the right people in a room together to design this problem out. However, that won't be able to happen for another few months.
I wonder if the standard library crates will need special treatment by this feature? For example, the link to the constant in docs needs to resolve to or depending if the docs are being rendered as part of the libstd or liballoc docs.
Small bug report (let me know if this isn't the correct place to report this): Currently, intra-doc links respect in a way that I'm not sure that they should. It means that simple links like fail to link to the correct place in the standard library documentation.
Well, it's part of the issue indeed. I'll add a bullet point for it.
The problem is that we use the same resolver that the compiler has made - which means that it's affected by . To universally load in libstd for intra-doc links, we either need to totally ignore when building docs (which may cause erroneous compilation errors) or have some way to find and load libstd's information (and prelude, since you mentioned specifically) after rustdoc takes over from the compiler. I'm sure it's possible, but it's more cumbersome than it seems.
It definitely seems like one of those cases where what is technically correct and what is expected are different, and we should design in favor of the latter. The easiest stopgap solution I can see would be to add a new compiler attribute, , so that users can write:
Do I get it right that , , are not supported for path resolution? does not seem to throw a warning of failed resolution where the other two do. However it creates a link as: which obviously doesn't work.
Hmm, they should work, but I think the implementation is buggy around them right now. On Tue, Apr 30, 2019, 7:18 AM Naja Melan <:
Ok, we do seem to have success with actually, but is definitely broken.
I didn't see it mention in the RFC or this issue, but is there a way to link to a documentation header in another crate? For example, I'd like to link to the syntax header of the regex crate. I can do something like this: But not something like this (which would be preferred, as that would link to the correct version of the syntax documentation):
No, intra doc links doesn't currently support linking to sections. It could. It doesn't support linking to other either, but that's trickier to get right.
What do you mean by this? Quick testing shows that intra-rustdoc links works fine with locally available docs, or specified in a dependency, or overrides on the command line. If you're referring to the fact there's no default external doc location when isn't set, that is independent of the intra-rustdoc feature, it will presumably just work if is updated to be able to default that.
I mean the general case of linking to an external crate on if it's not a dependency of yours or you are not on
Ok, so just , which applies to all links to external documentation including intra-rustdoc links.
I filed , in which the "module disambiguator does not seem to be respected.
I filed to propose support for linking to sections, [link text][MyStruct#my-section].
I filed about recognizing as an intra doc link.
I'm not fan of such things... For instance, what should we do with Vec<StringVecStringSomeType<T, U, V`".
I would be on board with linking if and only if the type parameters in the link match the names of the type's generic parameters, for example would get linked but would not.
That'd force to check all the generic parameters, not very ideal...
Would you be able to clarify what is not ideal about checking generic parameters? Is it difficult to implement? If that's the only thing, would you consider accepting a PR that takes care of the implementation?
No it's not difficult. It's just not ideal because it creates additional rules that I find useless. The goal of a feature is to be simple enough to let users use it without having to wonder: it something I can do? will be the outcome? In this case, we can consider that the first point wouldn't be an issue but the second definitely would.
It would be great if there were better support for rendering this style of linking then, currently they have weird spacing, opened about it.
While this is unstable it should at least produce warnings with non-nightly compilers to avoid catching users off-guard: Opened as
I see that has been merged to add support for primitive types, however I'm trying to link to as well, to test if it's just polymorphic primitives, and it seems that might be the issue, since it also doesn't work as a intra-link. Am I missing something?
It's still very unstable and experimental. A lot remains to be done. Can you open an issue about it and cc me on it please?
Would it be possible to have this resolve links to trait implementation? For example:
Normally it should work as is. But like said above, it's still very experimental.
It doesn't seem to work for me... on
This comment isn't very helpful... Can you provide us details like the markdown, the context, etc... ?
Fully reproducible example:
So, trait methods aren't working. Thanks for the feedback. Adding it to the points.
I filed to have the disambiguator stripped from the link text in something like .
Is there any centralised documentation for how exactly this feature works, considering how it's changed so much from the initial RFC? Like, specifically document what kinds of links should work and which shouldn't, and if parts of the text are removed from the final result? Like, I get that it's not going to be stabilised any time soon, but many folks use this feature and it's hard to reason which things work and which don't at the moment.
The only thing blocking stabilization now is
Isn't documentation also a blocker?
That's usually a part of stabilization.
Is there any way to hide any prefix when linking to types not within the current module and not in scope when using shorthand links? I notice in some of my documentation, I have some types imported, and can link to them using MyStructcrate::OtherStruct`, which looks a bit off in the documentation. I realise I can name the link whatever I want and then turn it into an actual link later by adding a reference, but that increases the bloat of the comment in the code itself. I guess it's a minor thing, and there's no clean way to solve this that isn't probably at least somewhat surprising to some, but I wanted to mention it nonetheless.
Have you tried something like:
One way that I tend to do this is using the (currently unstable, but pending stabilisation in ) . i.e., at the top of the file, I put: and then you can reference the type without the prefix. You can do this without the by simply adding , although I prefer the former as it will still lint if you don't actually use the import.
Could someone in the know please file an issue around "Handle fields inside struct variants" so that I know what might be needed in order to close off that blocker?
It's not a blocker. It's about giving the ability to link directly to a struct field by naming it in the link.
Isn't that ambiguous when there is also an inherent method with the same name? It's also "syntactically unnatural" to refer to struct fields in this way, though I can't think of a better way right now.
Yeah, that's why there's no issue for it, it's something we may want to add and if we do we'd have to figure out how. It's not a blocker. Thanks, -Manish Goregaokar Mikhail Zabaluev <:
Aha, thanks. I misunderstood the presence of something in the top comment with a tickybox as being something which had to be done. Is there an issue capturing the desire to link to a struct's field so that it doesn't get lost if this issue is closed? Or is there a process for splitting out remaining issues when we close a tracking issue?
We can file an issue now if you want, but basically any leftover non blockers will be filed as issues once this is closed. On Sat, Nov 9, 2019, 11:23 PM Daniel Silverstone <:
Okay, if raising issues when this closes is the process then that's perfect. I'm not in a rush to have that issue, I was just trying to properly understand (a) what was actually considered blocking for stabilisation, and (b) what the process was to deal with remaining things if it wasn't all blocking. Thank you for clarifying things
Cross crate imports and documentation are the only stabilization blockers AIUI. Documentation can be done during the stabilization process.
If someone wants to add docs earlier they can be to the unstable book, and then moved over to the reference.
seems like has a similar thing in progress at for
See also:
Oooh interesting, thank you. I shall have to have a look when gets closer to completion. I have plenty to be doing before I try for the better resolution, so if their work makes life easier for us, then that's excellent.
You should coordinate with them and see if there's a way y'all can work together! It's possible their work is already sufficient for your purposes here. On Sun, Nov 10, 2019, 11:52 PM Daniel Silverstone <:
When I tried using intra-doc links in libstd docs a few months ago, I was told they are still experimental and should not be used yet. What is the current status? When writing new docs / adding new links to existing docs, should I use intra-doc links?
Would it be possible to land the current intra-doc feature without cross crate imports? That would hit most of my needs for intra-doc resolution and still leaves open the option to land cross-crate imports later.
The problem is that anyone might re-export a type from your crate and then the documentation will be broken.
So the user of the feature can't know in advance when it will break. I guess we could still stabilize it with this caveat and request people to work with upstream authors to remove these links when reexporting.
If you're targetting docs built by it should be "fine". But as long as we don't have everything fixed, I don't think this is a good idea to stabilize it yet.
I don't if this is already on someone's radar but, linking to re-exported macros doesn't work at the moment. Simple test case: In : It fails with the following: Versions: rustc 1.43.0-nightly ( 2020-03-08) cargo 1.43.0-nightly ( 2020-03-02)
this is
This should be fixed now. See issue, MR,
Perhaps this is fixed now, see issue: MR: If not please. please provide a minimal example for it to clarify it.
I don't understand how to link to a re-exported procedural macro. The RFC indicates that linking to a macro is possible, but none of my attempts appear to successfully link. the- the-
the re-export is the problem, see As a workaround, you might be able to use the absolute path (), but I haven't tested that.
Yeah, that was one I tried in my project but didn't reflect in the reproduction. It didn't seem to work either. <details<summaryAttempts</summary</details
I'm not sure, right now cross-doc links are pretty broken. Hopefully will land in the next few weeks, you could try again afterwards.
the cross crate bug is unrelated to the one being described by You should totally be able to link to a in the current implementation, so what describes is an independent bug
Can confirm that linking to works, but not if it's a proc macro being used. Macro scoping is weird so that's probably it.
Oh, this has nothing to do with pub use, we're just completely incapable of linking to derive macros
Filed , thanks
Note: once lands all of the blocker issues for this will have resolved and we should be a go for stabilizing the feature with docs. Note that it has baked as nightly-only for ages now.
I'll write documentation once it's merged then. We still have a few other points which need to be solved before stabilization though, but we're getting close! :)
I haven't had time to make a minimal repro, but there still appears to be an issue with linking to free-functions on cross-crate inlined docs like even using the from .
I've already got some of the docs written. It's not clear to me if the remaining issues should block stabilization, I think they can be treated as just another bug. We don't typically block stabilization on minor bugs whose fix will not impact the feature.
Do we have a general consensus on what kinds of changes are considered major or minor when it comes to doc syntax?
I don't think there are or needs to be rigid rules around that. When a feature is considered for stabilization, the relevant team looks at the status of the feature, and decides if it's ready. Like I said, typically bugs where the fix is not likely to severely change the feature are okay to have. In this case the major blocker, the cross-crate issue, was one where we weren't even sure if it was possible to implement, and it might have changed how the feature worked. It was also just a major piece of functionality. The current remaining issues are linking to std: this is a quality of life improvement where you can still link to items from a crate. The other one is about linking to the docs of the slice primitive, which is also a quality of life improvement, since people do that rarely.
I don't think there need to be strict rules, but I was mostly asking because I figure that this might come up more as rustdoc becomes more robust and changes to its syntax can throw deny-by-default warnings. My general assumption is that regardless of whether something might "break" that docs are considered separate enough to ignore these issues in favour of pushing out changes sooner, but I figure that a potential clarification on that might be helpful to avoid this confusion in the future.
oh that's fair. When it comes to lints the general Rust stabilty model is that new warn-by-default lints are always okay, deny-by-default lints should usually go through some cycles of warn-by-default unless there are special circumstances.
Okay, so I've narrowed bug down to the check in failing. Removing that line lets the link work just fine.
Annoyingly, any attempt to narrow down the testcase is failing for me. What's happening though is that the defid is absent from the accesslevels map. I'm not sure why.
Aha, it's the . Moving that to the end of the file fixes the issue . I'll try to file a bug about this.
FWIW the following part doesn't seem to occur anymore. This might have been an issue during the edition changes to resolution
Removing the no_std issue in the list because is actually a broader rustdoc bug
FWIW, I support stabilizing even with the remaining bugs. This flag is already used pervasively, for example, I believe all of uses this.
There's a WIP PR implementing resolving intra-rustdoc links, and traditional path-based links, in rust-analyzer .
That's really great, thanks!
Should we add suggestions to part of the tracking issue? For example, Could be Or we could guide them to do (I personally am not sure how to do this, I wish I could help out with diagnostics )
I think this should be a separate issue, it shouldn't block stabilizing the feature.
File a separate issue. Also the diagnostics here should be to suggest IMO.
I think it's a fair bit more involved to introduce this diagnostic fwiw
Status update: All the code for this has been written (that I know of), it's just waiting on a very long PR trail: -Once that is done, we can make a stabilization PR . The beta release is on Tuesday, which this will most likely miss; if it miraculously makes Tuesday we'll delay stabilization until afterwards because makes a lot of internal changes and should see a full 6 weeks on nightly before making it to beta. Additionally I'd love to see merged before since I expect it to improve rustdoc's performance quite a lot. That shouldn't block intra-doc links, though. EDIT: this landed
feel free to include in btw, we can land both at once
I'd rather not, is a good change even if we have to revert . Also it can be rolled-up and shouldn't be.
Once that is done we'll have an initial functional implementation. The next step is testing it. A big part of that will be to start using it in the docs and seeing if it can fix the issues it was designed for (, ).
We have had a functional implementation for three years now. It has been used in the stdlib docs for ages, and is used across the ecosystem. The ability for reexports to work correctly was a blocker to stabilization, but it is not a huge feature that will be used a lot. The reason stabilization was blocked on reexports was that we determined that the bug fix could be complicated and might require rearchitecting the feature, which made us reluctant to stabilize earlier.
I hadn't seen these issues earlier, and we should absolutely fix them using intra doc links, but I don't want to block stabilization on that. We've had this feature mostly working for ages.
Alright, so the current status of this is that we have a stack of PRs blocking all remaining major issues (, ): - - - Between and myself, we hope to stabilize this shortly thereafter. will be filing an FCP but as we're currently mostly waiting for the final chips to fall in place, I wanted to front-load some of the discussions that may happen during that FCP. Hopefully when we make that FCP it is simply some rubber-stamping if we have these discussions earlier. What are your thoughts on stabilizing this shortly after the last few patches land? I recall having some concerns. I don't recall if has said anything on this point. My position on this (I think this is shared by Guillaume and Joshua) is that this feature has been cooking on nightly for three years now. The cross-crate import issue was a blocker not because it was a major piece of functionality, but rather because there was a chance we wouldn't be able to implement it in a neat manner and would paint ourselves into a corner by committing to it. It's clear that that's not the case. If we're worried about the code for cross-crate imports itself being broken, that's what the release train schedule is for -- we can undo these patches and stabilization for twelve weeks if this happens.
I think that once the remaining stack lands, we're in good shape to stabilise. There're bound to be corner cases we've not found etc. and documentation which could be improved, but getting this out and usable by the general developer community will be immensely useful.
has landed, so now we're ready for stabilization. should land soon
Stabilization PR is ready
After this is no longer the case. Should the RFC be updated?
go for it
Triage: has been merged, so its mark can be checked, I believe?
Hi, does someone knows how to write intra-rustdoc links to ? I'm not sure if this is not implemented or if I'm writing incorrectly. Have tried those, but they are not working:


After discussing it on the forums I bit I decided to look into what the optimizer spends time on, and inlining seems to be a significant part of it. There seems to be a lot of room for improvement here. Tested by compiling syntex in rustc-benchmarks (though the inlining time seem quite significant in other crates as well.). I counted which functions were inlined the most, and and to a lesser extent , which are when automatically deriving , and which simply wrap two other functions inside fmt::builder show up a lot. Maybe derive(debug) could output the wrapped functions instead, or the equivalent code, so llvm doesn't have to spend time inlining them (unless this causes problems for debug info). is also inlined a lot, and also plays a role in derive(Debug). Maybe something could be done about that one as well, as it's that creates a struct but doesn't do anything else. <details<summaryOutput from time-llvm-passes</summaryUsing in the syntex-0.42.2 directory in rustc-benchmarks. It's a bit hard to say which crate is which, as the output from llvm and cargo isn't synced, though these are the bottom three (excluding the benchmark dummy) in reverse order: </details<details<summaryMost inlined functions: </summaryRunning , and filtering the output using this: (Yeah it's a bit of a monstrosity, and takes a long time, maybe I could look into making some tool analyze this if it turns out to be useful.) gives: <pre1865 ZN4core3ptr13dropinplace17hffb7ed55089717f8E inlined into 917 ZN50Tascore..convert..FromTGT$4from17h99c56b7d2123957eE inlined into <b677 ZN4core3fmt9Arguments6newv117h0a32116e8ade096aE inlined into</b549 ZN4core3ptr13dropinplace17h8905708a4bea3261E inlined into <b517 ZN4core3fmt9Formatter11debugtuple17h312acfb009988478E inlined into</b484 ZN50Tascore..convert..FromTGT$4from17hf6536c6dc214691bE inlined into 438 ZN5alloc9allocator6Layout4size17h278602cb6317171dE inlined into 402 ZN63alloc..allocator..LayoutasGT$5clone17hba86f6db001903cdE inlined into 381 ZN61u20u20GT$7dealloc17h3db9762b4fdfd21eE inlined into 344 ZN5alloc4heap15exchangemalloc17he9800f033a6330e4E inlined into 341 ZN4core3ptr13dropinplace17hb5325e51b98a161aE inlined into ... <b82 ZN4core3fmt9Formatter12debug_struct17h5cfb920e90696799E inlined into</b... </pre</details<details<summaryrustc --version</summary</details
We should just drop the from those functions - debug printing is something we want to be optimizing on code size/compile time rather than perf.
Yup, that's a good point. EDIT: Actually since they're just generic over lifetimes it looks like that's not an issue.


In the following scenario, the user will have a better experience if we allow them to have an "unused" extern crate. If we permit them to write , as recommended by Serde's docs for this reason, the error message is: If they remove the unused , they generally get nastier error messages. If we can't fix the error message to be as good as it was before the unusedexterncrates warning, let's disable unusedexterncrates in cases where the same crate is used later in some nested scope (submodule or code block). cc who has been involved with this warning.
Arguable point. As the statement doesn't impact the binary (linkage), it doesn't harm if we disabled the lint. I'm not sure about the way to implement it though.
the above example works now without the requirement of . Is there anything else blocking this other than ?
Closing this as the error case is the same now irrespective of whether extern crate is included or not.
There is still a minor improvement from adding . Less bad compared to though.


Was looking at the printout of llvm passes when I noticed that the functions that was inlined everywhere, and due to this was dead code, was optimized more after inlining. So as a test I at the line and this reduces the compile time of release build in racer by an average of 23%. I do not know if this is a good place to add this extra pass but maybe someone that knows how llvm works can use this information to speedup the compilation of release builds. was also wondering how this works in MIR I see that there is an inline pass but I can not find any dead code elimination
the stage1 compilation of rustc went from 828.89 to 691.75 secs with this fix on my computer but that is only a 15% improvement
15% is pretty significant.
Wow, great work!
That's some nice improvements! If you feel up to it, go ahead an submit a pull request with your suggested changes. That way someone with experience with LLVM is guaranteed to look at the patch and it won't get lost.
I believe the PR should be targeted at
:+1: If you want to push through this patch the general process works like this: Submit the patch against the currently active branch of (which is at the moment) Wait for it to get reviewed & merged Submit a pull request against which updates the submodule. If you have any questions about the process or want someone else to do this, just mention it here or contact me or someone else on one of the .
cc
cc
Ideally, the process should include discussion with upstream LLVM too.
Unfortunately it looks like we were a bit too eager to close this in :(
From what I have learned from the llvm maintainers I think that we have received the improvement that can be expected. The to good to be true improvements I measured was probably due to less optimizations was possible and resulted in less optimized code.


The standard library provides a way to get the process id of a child process with , but doesn't have any way to get the current processes id (the equivalent of ). It is possible to do this with , but it seems to me that this should be something that is part of the standard library, especially since it already has cross-platform support for process ids of child processes.
Seems reasonable to add!
on Windows.
Reopening as the tracking issue.
While porting Rust over to , a sandboxed UNIX-like runtime environment, I ran into the issue that there is no way for me to implement this function. As we're aiming to use CloudABI in distributed settings, there is no traditional 16/32-bit process identifier. Instead, processes may be identified by a UUID. This is useful, as integer process identifiers can easily collide when dealing with many instances of a job (due to the birthday paradox). As this function was only introduced recently, would it still be possible to alter it to return an opaque, but displayable data type instead? That said, almost all of the other functions provided by this module are also broken on CloudABI. The traditional model doesn't lend well to sandboxing. Maybe it makes more sense to disable on CloudABI entirely.
I'm opposed a completely opaque data type, because that limits the usefulness. For example, that makes it difficult to use in C (or dbus) that require a PID. However, I think it would be alright if the it was a semi-opaque type with OS-specific API's to get the underlying representation (in std::os::unix, etc). However, that would break consistency with , which is already stabilized. I'm not sure how you would deal with that either.
As has mentioned, the ship has already sailed here due to . More generally, though. I'm not sure it makes sense to avoid supporting getpid of all things because some platform decided not to implement it.
One thing that would be low-hanging fruit would be to at least have some kind of type alias for this. On UNIX/Windows, it could be defined as . On CloudABI, it could be a string. That way, existing code that uses continues to build on existing platforms, whereas less conventional platforms can choose to implement this function differently.
Given this: and this: I’m inclined to stabilize as-is. (Returning .) fcp merge Hopefully the can eventually help a CloudABI port to "cleanly" implement this differently, or not at all.
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] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.


is only parameterized on lifetime. The types of the captured arguments are erased in the contained . Nothing restricts the aggregate from being or , so by OIBIT it's both. Thus this compiles: I'm not sure if there are any realistic ways to accidentally abuse this, but here's a deliberate example. The spawned thread will read the through the arguments, even while the main thread modifies it.


Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged


We this to OccupiedEntry a while ago, but weirdly not to the map itself.
Should we also add ?
Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.


Here's a code sample, narrowed down a bit from my program: When built with and run, it gets SIGSEGV on my Mac. (I poked around a little bit with lldb and it looks like is returning something we can't dereference. I couldn't investigate thoroughly because it wasn't showing source line information for whatever reason.) Without the , it doesn't segfault. Here's an lldb session with some basic information about the crash: I'm on macOS 10.12.6. target-cpu=native on my machine seems to mean haswell, according to .
Seems to be macOS-specific, can't reproduce this on Linux.
I can repro on my Mac. Early 2015 Macbook Pro, running macOS Sierra. It did not crash on my 1.18.0 install; first starts crashing on installed via rustup:
This may be which was as an LLVM bug.
triage: P-medium Seems likely to be an LLVM bug. If more data or dups turn up, we can re-evaluate.
I am experiencing something similar to this when compiling native on OSX. OSX [Edit] problem does not exists in nightly v 1.24. So perhaps a regression in LLVM 6.0?


The following code gets optimized as expected: However, if I let the code call an unknown function instead of return, the optimization disappears: That seems wrong, why should the optimization stop kicking in? The corresponding C++ code does not have any problem: (I briefly thought maybe unwinding is the problem, but C++ should have the same kind of unwinding here.)
suggested I try , and indeed, . However, the optimization is sound even with unwinding panics, so it should happen either way.
Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls with the attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently. So, to fix this, we'd have to remove this -- at least for where does not itself implement .
CC
Could this be preventing other optimisations than pointer equality folding? Cc
definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be , rather than , which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).
However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on is incorrect:
Triage: this optimization still does not happen.
Oh no, ended up triggering LLVM to close this again.


Consider the following code: If you try to compile this, you get the following errors: See the bug? Its because I used when I should have used It would be nice if the compiler, in its ever friendly manner, suggested the latter to me.
I volunteer.


Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.
Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .


Originally reported here: I don't understand the following sentence: Could someone parse this for me? To me, it reads like "to free memory allocated by a Vec v, create a new Vec w and drop it (i.e., w)". This is obviously not what it is intended. What's the role of the second Vec? Is this only in a context where v is empty but its memory not yet freed? If so, why wouldn't shrinktofit work in that case?
This refers to unsafe code that e.g. uses to allocate memory, and then s the to use the buffer in different ways (e.g., passing it to C, or implement a custom data structure over the allocated memory).


In core, fails maybe a few times per month. Linux x86_64. I have no further information.
alright, i don't suppose you'd happen to have any logs of the times it failed? I haven't been able to reproduce the test failing (i.e., the test function terminating successfully). Looking over the unwrap implementation I think it's basically impossible for the test to fail with a localized bug, since it's testing two linked-failure tasks who go through code that looks like this: so I think it is safe to say that exactly one of the tasks will hit the . What's more, the test case itself has the parent thread (the one the test harness will block on) block on its child using a future_result. Either the parent will hit the die above (in which case the test case will surely pass), or the child will hit it, in which case the child's failure should link to the parent through the parent's call (I checked the linked failure code to make sure taskgroup killing happens before AutoNotify messaging). So it might be just as likely the race is in getting failed out of the recv call. So far I've experimented adding delays into various parts of the unwrap implementation to see which paths this test actually exercises (the state space is not very large, so it is not a Research Problem :P ), but not seen the bug in any yet. Will continue the search another day. EDIT: reproduction successful. (I'd forgotten that there was a difference in failure semantics between when the tasks are in the main/root taskgroup and when they're running as a #[test]! Argh.) More later.
Would you believe this is the minimized test case for this bug? No unwrap involved at all. Depending on the sleep, the test will either work or not (i.e., the problem is when a failing task sends to its futureresult before the parent even starts to receive on it, the linked failure doesn't take effect). I'm not sure if this is an intended nondeterminism of , but I definitely wrote assuming it wouldn't happen that way. anyway one possible way to fix this is to change the last line of the test case to (which doesn't weaken the test case). I will meditate on this more to decide if that's the best way.
OK, what's going on here is linked failure doesn't propagate through a in the special case where the pipe has data and the task doesn't need to block for it. To "fix" this nondeterminism at its source would involve putting a check in the case of . As another example, consider this program, whose main task always succeeds. "Fixing" the nondetermism above would make this program sometimes succeed (if the parent recvs before the child sends) and sometimes fail (if the child sends and fails before the parent recvs). Introducing the extra killed check wouldn't require taking a lock (see ). But, I've always punted on the semantics of when a linked failure killing takes effect, and adding this check feels like a patchwork special-case rather than a principled semantics change. might have input on the matter?
Adding the check seems reasonable to me. In the case of failure, I think it's fine if things are somewhat nondeterministic, so I don't think it's a problem if the program above sometimes failed. What if we a sleep before ? It seems like in that case you'd want this to always fail, unless you turned off link failure.
Thanks for looking into this. I understand how misses its opportunity to fail but not why the 'assert' has any effect. This is similar to a problem I frequently run into where I expect test cases like this to work (by failing):
Yeah, those are annoying cases. It might be nice to have a spawn interface that, while letting the parent go off and do its own thing, also makes the parent block on the child (on all such children spawned this way) before actually task-exiting. This could be done with on top of a generalised interface, or it could work by stashing s inside the parent's and having the destructor wait on each one in the destructor (which is essentially a hardcoded version of how would also work).


This seems to be related to , though not entirely the same. I am in the process of ing my crate (multiple crates in a workspace project) v0.5.0 (from ). Instead of a normal compile process, I got this: :
I experienced this error now multiple times. Maybe it is a good idea to include the complete build output here:
With I get this error in a different form:
For the record: works on all crates where this bug was triggered (though I did not test all of them, just some).
For whatever reason, this is making it effectively impossible for me to package projects with lots of dependencies for Nix.
I can reliably hit this bug when compiling my project () with Nix
I believe this is a bug in our rustc package in nixpkgs, we appear to build it against which is bugged: https://nix- Maybe it would be a good idea to have a hard dependency on for rustc?
There is an issue here: rustc version 1.22.1 has in its lockfile, and the nix build appears to reliably trigger this bug while compiling . So we have a problem in nixpkgs that we cannot bootstrap using the binary distribution from rust- you are the author of , is there something we could do to workaround this bug for bootstrapping ? Or is it necessary to use a patched for compiling ?
the workaround would be to remove any ambient jobservers and let cargo/rustc manage it, if any
Can't we bootstrap using 1.23.0 binaries?
I can reliably hit this bug as well in nix
I can reliably hit this bug using . As far as I am aware I don't have any jobservers running.
I realized that the following issue was only occurring on nightly. However after the latest update this is now occurring on stable as well.
still persists using seems to happen because of this:
Can you please take another look at this. It appears that your diagnosis is wrong and many people are experiencing this issue. There is no workaround as far as I can tell and this is seriously workflow disrupting.
A misconfigured jobserver can still cause issues in rustc, and this error is indicative of a misconfigured jobserver in one way or another. This indicates an environmental problem rather than a problem in rustc AFAIK. If someone else manages to fix rustc we can of course merge, but I don't personally believe there's much we can do in rustc for this.
There is no other jobserver in my environment. I have checked numerous ways and am highly confident.
I am also getting the same error as when running entr with the reload flag. Throws the following error: According to the entr documentation whats happening is : 1) immediately start the server 2) block until any of the listed files change 3) terminate the background process 4) wait for the server to exit before restarting
I created an upstream issue for as well - it surrounds closing STDIN, which was in later versions for compatibility with some programs reasons - seems it then breaks with .
It sounds like the underlying issue is
A workaround for those using : It works for me with and 1.40.0 on Linux.
This is no longer happening for me. I don't know what has changed but I don't see this anymore.
It still happens for me with and . Just tested it with and got a panic starting with the same bit.
So, I've found an entirely legitimate way to trigger this error (the "early EOF on jobserver pipe" case) on new versions of , without having stdin closed or anything other exotic setup. If you call from an outer -based build system then will receive file descriptors for the jobserver pipe through an env var called . Except that new versions of will mark those descriptors as so they will be either dead or, worse, replaced with other random files when tries to access them :D The solution is to prevent from closing the pipe by using string anywhere in the command. (Yep, that's how works - ) This is silly, but it seems like doesn't leave any other way to inherit jobserver (at least not readily available from higher level makefile generators).
was recently facing similar issue while trying to run cargo build inside a makefile with buildroot was facing this everytime when i run cargo build Build fails: error: failed to acquire jobserver token: Bad file descriptor (os error 9) This worked for me. MAKEFLAGS= JOBS= cargo build
If you are actually running cargo inside of make you are hitting a different problem and I recommend opening a different issue. This issue was about a bug where no job server was running. This issue was fixed.


Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:


Former-XXXes say "is this right?"
Clearing milestone because it's not obviously blocking anything. -- what test case(s) would answer the question you asked in a comment ("is this right?")?
Visiting for triage; FIXMEs are still there.


is probably the same issue.
Not a dup of
or rather, with the fix applied, I get another ICE =)
That new ICE seems similar to :)
Hmm, yes, but it's definitely not an issue with
This probably has something to do with the fact that consts use the identity substitutions when computing universal regions substitutions: since those are always going to be generating regions: I have yet to track down the code that should be resolving those early bounds and why it isn't doing so.
Hmm, you are in the right area of the code. But I think the problem runs just a touch deeper. Actually the comments here are not that great. I should do a pass to improve them. But let me try to first explain what's happening a bit and then how to fix it. The role of the enum (which should perhaps be renamed?) is to kind of capture the "external signature" for a given piece of MIR, and ideally in a way that identifies all of the "degrees of freedom" that the code has (and just those degrees of freedom). Based just on the defining-type, we should be able to identify the following information: The universally bound regions (i.e., lifetime parameters), both early and (where relevant) late bound The types of all the MIR inputs (expressed in terms of these universally bound regions) The types of the MIR output (expressed in terms of these universally bound regions) This is perhaps easiest to explain with a function item. Assume that we are working with the MIR for this function : In that case, the defining type will be the variant: You can see that it is actually sort of minimal: just a def-id and a substs array. In this case, the substs array will consist of three things, first a lifetime variable (representing ) and then two types (, as it happens): (This array gets created in ; this will basically replace the formal lifetime parameter of (represented as an ) with a fresh variable .) Given the array, we can easily compute the set of region variables representing universally bound regions in a function signature -- it's just the region variables appearing in the substs array. That's what we use to build the map in . Note that this substs array does not, for example, include the types of the arguments etc. That's because those types can be reconstructed using queries. For example, the function includes this code, which extracts the function signature (using the query) and then basically substitutes (the call has that effect) from the formal lifetime parameters: Part of the reason it is done this way is that then the types of both arguments ( and ) will reference the same lifetime (). If, when creating the defining type, we had on something that contained the types of those arguments separately, then they would have been rewritten to use two different lifetime variables. This would have been too many "degrees of freedom". For constants, our defining-type variant is currently the type of the constant: This is actually wrong, and is roughly the equivalent of storing the types of the arguments directly in the . The fault arises from in -- it was written with functions and closures in mind. It fetches the "type" associated with the def-id and rewrites all the regions in it. This is ok for functions and closures because the type of a function or closure is already a kind of indirection; e.g., a is . We probably want to change that variant to something more like Fn: then we want to do is to refactor somewhat. I would expect it to look more like the following. This is the same as the existing code, just rearranged so that it only executes for : meanwhile, for and , we'll do something slightly different. We don't want to start by fetching , because that gets the type associated with the static. Instead, we'll do: Then we can change the other bits of code to match. For example: becomes When we wish to compute the "return type" of the closure, then we can do the query: becomes: I think that ought to work. cc


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


Repro: The same happens for 1.23-stable.
does this still reproduce?
no repro for .


is implemented for Range<T. TrustedLen that the upper bound of is None if the iterator produces more than elements. to produce its result. The of subtracts the lower from the upper value and casts it to usize. This is for u32. On 16bit platforms, the result of the subtraction of two u32 values may not fit inside , producing an invalid . This means, that e.g. collecting into a Vec using its allows writing beyond its reserved buffer. One such example input would be . Reference: /cc


I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet


In , the NLL checker incorrectly judges to be borrowed more than once: I get this error: This works without NLL. This was found while trying to bootstrap rustc with NLL enabled, where it manifests as:
cc
This is a case where our debug flags are very helpful for isolating the cause of a bug like this. Step 1: Remove from the example. Step 2: Incrementally work way to recreating effect of ; my hypothesis is (well, was) that this bug was injected by either mir-borrowck or, somehow, by NLL itself... lets test that hypothesis: I was scratching my head at this point... and then it hit me:
ah, good catch! I guess this is because those mutable borrows are "activating" at this later point? Fascinating.
I'm going to take a look at this bug.
Here's the MIR dump I managed to extract: <details</detailsAnd its corresponding MIR dump looks like the following: <details</detailsIt's probably not that important to look at the MIR dump, because the second line of the RUSTLOG output contained this: Where the last parameter is the value of , which strikes me as odd since a Reserved borrow should be able to be mutated... Oh wait, perhaps I'm wrong? Is this supposed to be activated before being mutated? Note that _4 is a temporary created by MIR that will be used to call .emit() upon.
I think what is happening is not that surprising. I don't think it's related to the flag, really. can prob confirm, but I think it goes something like this. Let's simplify to two arms. I think you'll find this has the same error: I've also labeled the two borrows that occur. Now, the control-flow is something like this: As you can see from the diagram, borrow B2 is already active when borrow B1 is activated. This is in part why the initial RFC for two-phase borrows was limited to the temporaries created for method calls: I wanted to ensure that the temporary was (a) assigned once and (b) that assigned was postdominated by a use which was dominated by the one assignment.
I'm a bit surprised though that this doesn't work now. Maybe PR that limits two-phase borrows hasn't yet made it into nightly? Would be good to verify whether this still activates with the latest master.
So I just rebased against master, and I still run into this exact same bug. which PR were you referring to?
I was referring to cc thoughts?
Hmm I wonder if is still too naive? I’ll try to investigate tomorrow
(I've started looking at the dataflow state, via . The initial information I'm getting from there is confusing me at best, so I'm not sure yet what conclusion to draw from it. Will report more later once I've delved into it a little more deeply.)
So, looking at the dataflow graph (after the dataflow has been run, so the entry sets contain the fixed point results), generated via , and also inspecting the debug output immediately before the error is issued: ... (this data is based on niko's reduced example from The dataflow is concluding, on entry to bb7, that both of the borrow (bb3[2]) and the borrow (bb2[0]) are reserved, and the bb3[2] is also active (since it was used in the invocation of on the bb3 terminator). Thus we get an error that it is not valid to have two simultaneous multiple borrows of . One logical step to take next would be to compare against the dataflow that is derived when we do not have two-phase-borrows turned on. I am going to do that in a bit.
The bug here is probably that we are erroring on having two mutable-borrows of the same path reach the use of in (bb7[0]). I often get the details wrong; I suspect that the issue is that we should solely be detecting conflicts between mutable borrows of a given path at the point where the borrow is taken (i.e. the points were we do ). Or to use the two-phase borrow terminology, the point where the borrow is reserved. Here, we are checking for it at the point where the borrow is activated (the use of in ). And so that explains why we do not see the problem without two-phase borrows turned on. When two-phase borrows are turned off, the check in question is performed at the point of reservation (since activation points are irrelevant when two-phase borrows are turned off).
I believe that is roughly the same , right?
Well, let me read your comments more closely, because I'm confused which borrow is not activating.
there's some differences compared to your diagnosis, but I don't know if they matter. For example, your hypothesized control flow graph has two activations that reach the same control flow point. The actual graph has a reservation on one path (but no activation), and the other path has a reservation and an activation.
So, the thing that is confusing me from the output is that the borrow appears not to be activating. However, I believe that comes from , and that (per your recent changes) ought not to be two-phase. (Note: this might also need )
An update regarding the previous comment: We discussed further on ; to summarize, I think that the intention is that two-phase borrows have no effect on the dataflow -- instead, their effect is meant to be encoded solely in the borrowcheck code itself. Specific to this case, the dataflow only shows a reservation, not an activation, at the statement , because that is indeed just the initial borrow of , not the use of `4, and its the job of the borrowcheck code to actually react properly to that reservation.
After even further discussion on gitter and also in video chat, and came to the conclusion that the answer here is probably not a surgical fix covering a small number of lines, but rather a slightly larger-scale (but mentorable) effort to redo two-phase borrows so that it more closely matches the original intention of the RFC. See


should document that , , and are all mutually exclusive. (and that it may also be the case that none of them are true) Why? Because returns true for both files and symlinks to files, and this tends to make me paranoid that a will share similar characteristics and perhaps claim that both and . The only way to convince myself that FileType's behavior is indeed sane is to write a little test program---again. Surely I can't be alone in this.
is calling not (and equivalent on Windows), so if the path is a symlink, then it returns the results based on what the symlink points to, not the symlink itself. So respects the same mutual exclusivity rules as . But yes, this ought to be documented, especially given that the mutually exclusive behavior may be surprising to Windows developers.
Similar goes for , which should document that these are always false for a obtained by calling on a symlink.
Well you can always call on something that is not a symlink, in which case or could be true.


This ICEs with 'tyregion() invoked on in appropriate ty: tybot' from Full output from : Sorry for making the poor compiler throw up with my bad code. :(
"Sorry for putting in effort to make your compiler better with no personal gain", you mean! :-D
Can't reproduce this anymore.


Tracking issue for , and . Steps: [X] Implementation [X] Stabilization PR () Unresolved questions: [X] What is a good name? ? ?
cc


The following crash occurs during incremental compilation of the rust-url crate: https://travis- cc
minimal repro:
remarked on IRC that this might be temporarily worked around by not caching upstream constants.
triage: P-high Regression.


Documentation on states: However, this code panics on both store and load (if the call to store() is commented out) Either documentation should be updated to describe why this is not relevant to store/load, or implementation should be fixed to actually deliver on the promise.
The implementation is correct. AcquireRelease is an ordering for operations that both load and store. If you just have a load or a store, you can and should simply use acquire or release respectively.
Ok, makes sense. Then the documentation should reflect that more clearly.


Nobody responded to , and the rabbit hole has only gotten deeper and deeper since I've started trying to work around this . It's time for an issue. Here's a simple pattern macro: Trouble is, suppose somebody writes . Then they'll get this: Here is the simplest alternative I can come up with for working around this warning in this simple macro. Notice how proper support for and requires that the macro output uses shorthand field syntax, as opposed to a more scalable workaround like (where the is at least something that could be produced by a helper macro). A similar pattern macro for a struct with two fields basically requires an incremental muncher now, just to avoid the exponential blowup of rules. This is an awful lot of headache just for a little reminder to write more idiomatic code! Isn't that clippy's job, anyhow?
A crude fix would be to just not trigger this lint in macro expansions (at the cost of missing out on linting macro code where the offending non-shorthand pattern doesn't come as an argument, which, ideally, should be linted):


I have a Rust written using the msp430 backend. which means using the nightly compiler. Travis CI daily cron builds have been with the nightly compiler since March 27, 2018 with the following error (I am currently not in a position to get a backtrace/increase verbosity, I will update when possible): My msp430 firmware uses to create a for msp430 every time is updated, and recently a new feature has triggered a lint that causes compilation to fail due to an unused macro. Since can't be compiled, the whole build fails. A stopgap solution for now is to use a nightly before March 27, 2018 which compiles for msp430 successfully. cc: based on a in with PR might have tickled the lint into failing compilation for the msp430 backend?
This macro is conditionally used in code that depends on the target’s pointer width. I suspect that this error happens on any 16-bit platform. Adding to the macro’s definition should fix it. Would you send a PR and ping me for review? (As an aside, we should probably have CI on rust-lang/rust that libcore at least compiles for one 16-bit platform.)
Looking at 's fix I guess my q is: why don't 16 bit targets (msp430/avr) need this macro at all?
has some background on the removal of conversions for some combinations of integer types. Here we have a private trait with a generic impl based on and some concrete impls to "restore" missing conversions. The implementation of those concrete conversion depends on the size of : we either check that the source value isn’t too large for the target type, or check nothing at all because the target type covers all values of the source type. When is 16-bits, the minimum, only the latter kind of conversion is used.


Given a procedural macro like so: and an invocation: you get the following when compiling: In addition to the panic (oh dear!) we can see here that is showing up in the tokens by accident. The attribute should have been removed during the tokenization when passing to the procedural macro! I believe this is another instance of
cc


Caught while fleshing out a much beefier test suite for SliceIndex, which I plan to submit as a PR. (this Issue is here just in case that PR never happens). The unicode character boundary check here should be looking at . Better yet, the method could just delegate to instead. (note: it can't delegate to here without NLL, which seems to be a leading factor as to how this function ended up this way)
Not technically a regression but tagging it as such to ensure that we don't forget about it.
my commit message accidentally closed this, which might defeat the purpose of the tag you (note: I myself can't reopen it because Github attributed the message to Bors)
Oh that's ok, the tags on the PR take over now for backporting and that's how we'll track this.
(ahhhh, now I see. The tag is used in automation for a Github Project to track regressions. That's actually pretty cool!) ('t mind me, just talking to myself)


When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.


I came across . This is a "safe" feature of rust I didn't know about. I was at first confused about the docs for however. My main confusion was around the "deinitializing" word which made me think that is not consumed. It is consumed but it is not dropped, which is a subtle distinction. I propose here to remove the confusing language. Suggested new docs: Another possible option (I don't like it as much but it is more similar to the previous docs): As a side note, I have not seen the "deinitialized" qualifier in rust before. I don't think it is part of the standard rust lingo which is probably some of my confusion :smile:
Another option, which I think is the best of both worlds: The important points are to mention that is moved, and to use standard terminology rather than "deinitialized".
I like the third option the most:
I have to say I like yours the best. Maybe change "Moves behind the mutable reference" to "Moves into the mutable reference"? I'm not sure "behind" is standard lingo either :smile:
opened a pr


Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.
sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.


rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.


Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed


This is similar to the same buggy behavior we saw for matchers fixed in 1.20.0. For example in Rust 1.19 the following code fails to compile with the message , but correctly prints followed by as of 1.20. The matcher is currently broken in the same way. rustc 1.28.0-nightly ( 2018-06-09)
The ident issue was , so mentioning who fixed that one in . Would you be interested in taking a look at this similar case?
Duplicate of . should still be working on it I think?
Thanks! Let's continue to track this as part of .


When I build this code on nightly... ...I get these errors: The first error is fine, but the second one is missing the first character of . It looks like rustc assumes the first character is an and removes it without checking. :
Currently working on a fix here: Still need to add UI tests, which I'll do once I figure out how they work.
Adding to the Rust 2018 Edition Preview milestone. Has a pending PR, too.


If I return a direct type that is , I get a helpful compiler warning: The equivalent (and I believe preferred) code using gives no such useful feedback: Amusingly, this isn't a new problem, as returning a boxed trait object also has the same problem. It's arguably worse there because you've performed an allocation for no good reason, but it's also less likely because people are more reluctant to introduce unneeded allocations.
Since Rust 1.27 stabilizes (on functions), one possible solution would be a lint that checks the compiler-known type underneath the and the function returning it. If the type has the annotation but the function does not, it could suggest adding the attribute to the function.
I think it would make sense for to quickly review and agree on how we should handle this. A lint seems plausible. Inside the same module, where we know the concrete underlying type, it would definitely make sense to pass through the . I'd love to know if it makes sense to automatically pass through the on the concrete type when used from outside the module, so that this can work automatically without needing a lint and a manual additional on the function.
Why is the not on, say, ?
I agree with that traits seem like the better solution here than trying to "leak" must-used-ness.
In that case, is it fine that returning an of real type will drop the must-used-ness? Maybe we should suggest to the author of the function to add the attribute to the function if the real type is
Right, there's nothing meaningfully tying such a function to , if is hidden.
The new thing being stabilized in 1.27 is specifically on functions and methods (). on types, including the iterator-adapter structs like , are .
We may need to add an arm for in this match?
So, I'd absolutely support adding for traits, which would have the same effect on a function returning as on a type T would have for a function returning . However, I also think we ought to handle this case somehow, preferably in a way that doesn't require the user to manually propagate outward on every function that returns a type.
I don't think we should. The type, including its must-use'dness, is not a part of the public API in that context. If you want the function return to be treated as must-use, the solution in that case is to tag the function as must-use.
Then in that case, would it make sense to have a lint suggesting propagation of from the type to the function that returns that concrete type?
I don't think so. The point of returning impl Trait is to hide the return type and the facts of its API, the fact that the type is must-use seems no different from other facts about the return type.
As alluded to above, I argue that this is a bug in the must-use lint due to its antedating impl-Trait; I don't see sufficient cause here to complicate the language with another lint or feature. A pull request is forthcoming.
Hm, perhaps this was too confidently worded: see description of the new pull request .
So let me summarize to see if I understand correctly what you're planning for must_use for traits:
I think expanding the applicability of mustuse should probably be introduced using an RFC. It seems to me that there are two different approaches proposed and an RFC could clarify why we chose a certain approach: proposes to evaluate the lint using the concrete type and provided a PR to this effect. This is incompatible with statement with which I agree with: "The type, including its must-use'dness, is not a part of the public API in that context [i.e. return impl Trait]". I also agree with that mustuse for traits is something we should investigate and pursue. This would be extremely helpful for futures because forgetting to poll needs to be obvious.
Can you provide an example of a case where it is the correct thing to return a concrete type that is tagged as through and not use the result of the function? My original premise is that this is an unintentional mistake in 95-99% of the cases, which feels like the ideal case for a lint. In the (rare) case where the author of the -returning function deliberately wants to allow forgetting to use the return value, they can allow the lint. I don't know exactly which "other facts" you mean, but I can think of two primary things: "sub" traits, which are not automagically propagated: traits, which are automagically propagated: I think that the case is different from the "sub trait" case because you will rather quickly run into "well, my code doesn't compile" errors when you forget to return the "sub trait". You then have to decide if you meant to expose that interface. I know the auto trait aspect was much discussed, so I don't wish to re-litigate it. My point here is that we : I think there's a case to be made that is already an ergonomics-based feature as it helps prevent the user from writing code they didn't mean to.
As a concrete side note, I opened this because I did it myself: I wrote some code that returned and was confused for a minute because the compiler didn't have any warnings. I'm used to those warnings and they are part of my development flow. Having them "suddenly go missing" just because I wanted to use felt like trying to step on the last stair that isn't there. For me, it's right up there with in that my "normal" flow of programming that I've established since ~Rust 0.12 doesn't quite work the same with .
IMO the more conservative approach would be to not leak mustuse on the concrete type. If that turns out to be the wrong call, it can always be later. I think defining mustuse on traits (e.g. on and ) will already be enough to catch all the bugs we're trying to prevent. The big advantage of defining mustuse on the trait is that this system can also work for unnameable types like the return type of an async function. Additionally it also avoids all the boilerplate code that defines each concrete iterator or future type as muchuse.
I think the current approach of "stick on the dozens of types implementing and " just doesn't scale and this is an example where it goes wrong. Also consider type parameters or associated types that are known implement those traits. IMO they should get the same treatment by , without knowing the concrete type.
To be clear, I'm totally happy with implementing for traits, but that particular option has been available "forever" but doesn't seem to be implemented for whichever reason. On the flip side, fairly quickly. I really just don't want to see this particular feature held up by a months (years?) long discussion of the ideal Platonic implementation of for traits. Isn't that what the current implementation does? Am I missing something? I believe that's what I'm proposing... Yes, I believe that that's a better option, and I'll add one more: presumably it will also work for trait objects. I just don't want to lose what existing ergonomics we have until someone implements for traits. These don't even have to be mutually exclusive options! The lint can catch cases that a trait wouldn't — such as when a given instance of a trait should be must use but not the trait itself. The lint could even be removed once the better solution is created, if we felt it didn't carry its weight anymore.
I also want to suggest a more aggressive approach: existential is always no matter of its underlying type. If a function is returning an thing, you were probably meant to use it in some way.
I wonder how hard it would be to turn such a thing on to see the impact.
Thanks for the compelling argument! I agree with what I think is the implication of your post: this question boils down to "Is more like an auto trait, or a regular API fact?" I'm not sure of the answer. What is the distinction with vs any other return type? Isn't it plausible that something that returns also has a useful side effect, and the return is not relevant all the time?


I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.


I was in the middle of bisecting on system llvm and running when I noticed that, in fact, while each step was rebuilding the compiler with the changed llvm correctly, the test that was being run was never recompiled, such that the same one was always running, and my bisect was guided by wrong results. STR: Run once Touch anything that is part of e.g. , e.g. Run again Expected result: Both and the test are rebuilt, and the rebuilt test executed. Actual result: is rebuilt, the test is not, and the test built before the codegen changes is executed.


Playing with the nighly's existential types, I stumbled upon a compiler stack overflow: Error message:
A better example might be this: removing the from the existential type decleration just compiles fine
Can you try running the compiler inside gdb and produce a backtrace?
<details<summaryBacktrace:</summary</details
It's recursing in Ideally this should cause cycle errors. But I'm assuming Manually computes this without a query. Maybe we should just make a query? This would solve both the FIXME and this issue.
Both examples now produce a cycle error. So we just need to add the two examples to (if there aren't already tests for these situations)


These are the most common tools for concurrency in Rust. They should always be at hand.
Also
If we add we should also add and .
Agreed
Fixed by brson's commit.


As of we'll be updating to a version of the RLS which depends on racer which depends on . Unfortunately we're bringing in two different versions of , 209 and 211, right now. These should be deduplicated as they take a good deal of time to build on CI, and then we should also add a check which ensures that there's only one version of in our workspace. cc
I've sent a PR to update racer as part of
This is fixed by