The strategy is this:
- we compute SCCs once all outlives constraints are known
- we allocate a set of values **per region** for storing liveness
- we allocate a set of values **per SCC** for storing the final values
- when we add a liveness constraint to the region R, we also add it
to the final value of the SCC to which R belongs
- then we can apply the constraints by just walking the DAG for the
SCCs and union'ing the children (which have their liveness
constraints within)
There are a few intermediate refactorings that I really ought to have
broken out into their own commits:
- reverse the constraint graph so that `R1: R2` means `R1 -> R2` and
not `R2 -> R1`. This fits better with the SCC computation and new
style of inference (`->` now means "take value from" and not "push
value into")
- this does affect some of the UI tests, since they traverse the
graph, but mostly the artificial ones and they don't necessarily
seem worse
- put some things (constraint set, etc) into `Rc`. This lets us root
them to permit mutation and iteration. It also guarantees they don't
change, which is critical to the correctness of the algorithm.
- Generalize various helpers that previously operated only on points
to work on any sort of region element.
rustc: Lint against `#[macro_use]` in 2018 idioms
This commit adds a lint to the compiler to warn against the `#[macro_use]`
directive as part of the `rust_2018_idioms` lint. This lint is turned off by
default and is only enabled when the `use_extern_macros` feature is also
enabled.
The lint here isn't fully fleshed out as it's just a simple warning rather than
suggestions of how to actually import the macro, but hopefully it's a good base
to start from!
cc #52043
This commit adds a lint to the compiler to warn against the `#[macro_use]`
directive as part of the `rust_2018_idioms` lint. This lint is turned off by
default and is only enabled when the `use_extern_macros` feature is also
enabled.
The lint here isn't fully fleshed out as it's just a simple warning rather than
suggestions of how to actually import the macro, but hopefully it's a good base
to start from!
cc #52043
Add ExactChunks::remainder and ExactChunks::into_remainder
These allow to get the leftover items of the slice that are not being
iterated as part of the iterator due to not filling a complete chunk.
The mutable version consumes the slice because otherwise we would either
a) have to borrow the iterator instead of taking the lifetime of
the underlying slice, which is not what *any* of the other iterator
functions is doing, or
b) would allow returning multiple mutable references to the same data
The current behaviour of consuming the iterator is consistent with
IterMut::into_slice for the normal iterator.
----
This is related to https://github.com/rust-lang/rust/issues/47115#issuecomment-392685177 and the following comments.
While there the discussion was first about a way to get the "tail" of the iterator (everything from the slice that is still not iterated yet), this gives kind of unintuitive behaviour and is inconsistent with how the other slice iterators work.
Unintuitive because the `next_back` would have no effect on the tail (or otherwise the tail could not include the remainder items), inconsistent because a) generally the idea of the slice iterators seems to be to only ever return items that were not iterated yet (and don't provide a way to access the same item twice) and b) we would return a "flat" `&[T]` slice but the iterator's shape is `&[[T]]` instead, c) the mutable variant would have to borrow from the iterator instead of the underlying slice (all other iterator functions borrow from the underlying slice!)
As such, I've only implemented functions to get the remainder. This also allows the implementation to be completely safe still (and around slices instead of raw pointers), while getting the tail would either be inefficient or would have to be implemented around raw pointers.
CC @kerollmops
make pretty source comparison check be fatal (fixes#52255)
This is not ready for merging because it reveals (at least) two regressions in the pretty suite. Should I attempt to fix those in this PR also?
Rollup of 9 pull requests
Successful merges:
- #51816 (bootstrap: write texts to a .tmp file first for atomicity)
- #51912 (impl Clone for Box<CStr>, Box<OsStr>, Box<Path>)
- #52164 (use proper footnote syntax for references)
- #52220 (Deny bare trait objects in `src/bootstrap`)
- #52276 (rustc: Verify #[proc_macro] is only a word)
- #52277 (Uncapitalize "If")
- #52287 (Deny bare trait objects in src/librustc_resolve)
- #52295 (Deny bare trait objects in src/libsyntax_ext)
- #52298 (make reference to dirs crate clickable in terminals)
Failed merges:
r? @ghost
make reference to dirs crate clickable in terminals
Currently I have to copy-paste the link; with this change I can just click it right in my terminal window.
rustc: Verify #[proc_macro] is only a word
... and perform the same verification for #[proc_macro_attribute], currently
neither of these attributes take any arguments.
Closes#52273
bootstrap: write texts to a .tmp file first for atomicity
If you are using a hard-linked file as your config.toml, this change will affect the way other instances of the file is modified.
The original version would modify all other instances whereas the new version will leave others unchanged, reducing the ref count by one.
rustc: Search all derives for inert attributes
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
