Fix some doc links
The futures crate CI always fails because of these intra doc links. I hope that this will fix this issue.
r? @steveklabnik
@cramertj
Edit: I added @steveklabnik as reviewer because this PR also adjusts a link in `src/libstd/error.rs`
Stabilize Iterator::flatten in 1.29, fixes#48213.
This PR stabilizes [`Iterator::flatten`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.flatten) in *version 1.29* (1.28 goes to beta in 10 days, I don't think there's enough time to land it in that time, but let's see...).
Tracking issue is: #48213.
cc @bluss re. itertools.
r? @SimonSapin
ping @pietroalbini -- let's do a crater run when this passes CI :)
Speed up compilation of large constant arrays
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
With this change, the [toy program](c2f4744d2d/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine.
Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine.
Edit2: Now down to 2.8 seconds.
r? @oli-obk
cc @nnethercote @eddyb
It was pointed out in review that the glob-exported
underscore-suffixed convention for `Spanned` HIR nodes is no longer
preferred: see February 2016's #31487 for AST's migration away from
this style towards properly namespaced NodeKind enums.
This concerns #51968.
NLL: bad error message when converting anonymous lifetime to `'static`
Contributes to #46983. This PR doesn't introduce fantastic errors, but it should hopefully lay some groundwork for diagnostic improvements.
r? @nikomatsakis
Suggest correct comparison against negative literal
When parsing as emplacement syntax (`x<-1`), suggest the correct syntax
for comparison against a negative value (`x< -1`).
Fix#45651.
A fix for 51821
This dedupe the vec of `OutlivesConstraint` using a `FxHashSet<(RegionVid, RegionVid)>` it alsow adds a `struct ConstraintSet` to encapsulate/ensure this behavere.
Always check type_dependent_defs
Directly indexing into `type_dependent_defs` has caused multiple ICEs in the past (https://github.com/rust-lang/rust/issues/46771, https://github.com/rust-lang/rust/issues/49241, etc.) and is almost certainly responsible for #51798 too. This PR ensures we always check `type_dependent_defs` first, which should prevent any more of these (or at least make them easier to track down).
April 2016's Issue #33174 called out the E0446 diagnostics as
confusing. While adding the name of the restricted type to the message
(548e681f) clarified matters somewhat, Esteban Küber pointed out that we
could stand to place a secondary span on the restricted type.
Here, we differentiate between crate-visible, truly private, and
otherwise restricted types, and place a secondary span specifically on
the visibility modifier of the restricted type's declaration (which we
can do now that HIR visibilities have spans!).
At long last, this resolves#33174.
If the item is `pub`, one imagines users being confused as to why it's
not reachable/exported; a code suggestion is beyond our local knowledge
here, but we can at least offer a prose hint. (Thanks to Vadim
Petrochenkov for shooting down the present author's original bad idea
for the note text.)
While we're here, use proper HELP expectations instead of ad hoc
comments to communicate (and now, enforce) the expected suggestions in
test/ui/lint/suggestions.rs.
This is probably quite a lot less likely to come up in practice than the
"inherited" (no visibility keyword) case, but now that we have
visibility spans in the HIR, we can do this, and it presumably doesn't
hurt to be exhaustive. (Who can say but that the attention to detail
just might knock someone's socks off, someday, somewhere?)
This is inspired by #47383.
There are at least a couple (and plausibly even three) diagnostics that
could use the spans of visibility modifiers in order to be reliably
correct (rather than hacking and munging surrounding spans to try to
infer where the visibility keyword must have been).
We follow the naming convention established by the other `Spanned` HIR
nodes: the "outer" type alias gets the "prime" node-type name, the
"inner" enum gets the name suffixed with an underscore, and the variant
names are prefixed with the prime name and `pub use` exported from here
(from HIR).
Thanks to veteran reviewer Vadim Petrochenkov for suggesting this
uniform approach. (A previous draft, based on the reasoning that
`Visibility::Inherited` should not have a span, tried to hack in a named
`span` field on `Visibility::Restricted` and a positional field on
`Public` and `Crate`. This was ... not so uniform.)
Visibility spans were added to the AST in #47799 (d6bdf296) as a
`Spanned<_>`—which means that we need to choose a span even in the case
of inherited visibility (what you get when there's no `pub` &c. keyword
at all). That initial implementation's choice is pretty
counterintuitive, which could matter if we want to use it as a site to
suggest inserting a visibility modifier, &c.
(The phrase "Schelling span" in the comment is meant in analogy to the
game-theoretic concept of a "Schelling point", a value that is chosen
simply because it's what one can expect to agree upon with other agents
in the absence of explicit coördination.)
Avoid needless allocations in `liveness_of_locals`.
We don't need to replace the heap-allocated bitset, we can just
overwrite its contents.
This speeds up most NLL benchmarks, the best by 1.5%.
r? @nikomatsakis
