Joshua Netterfield reported an ICE when the unused-parentheses lint
triggered around an async block (#54752). In order to compose an
autofixable suggestion, the lint invokes the pretty-printer on the
unnecessarily-parenthesized expression. (One wonders why the lint
doesn't just use `SourceMap::span_to_snippet` instead, to preserve the
formatting of the original source?—but for that, you'd have to ask the
author of 5c9f806d.)
But then the pretty-printer panics when trying to call `<pprust::State
as PrintState>::end` when `State.boxes` is empty. Empirically, the
problem would seem to be solved if we start some "boxes" beforehand in
the `ast::ExprKind::Async` arm of the big match in
`print_expr_outer_attr_style`, exactly like we do in the
immediately-preceding match arm for `ast::ExprKind::Block`—it would
seem pretty ("pretty") reasonable for the pretty-printing of async
blocks to work a lot like the pretty-printing of ordinary non-async
blocks, right??
Of course, it would be shamefully cargo-culty to commit code on the
basis of this kind of mere reasoning-by-analogy (in contrast to
understanding the design of the pretty-printer in such detail that the
correctness of the patch is comprehended with all the lucid certainty
of mathematical proof, rather than being merely surmised by
intuition). But maybe we care more about fixing the bug with high
probability today, than with certainty in some indefinite hypothetical
future? Maybe the effort is worth a fifth of a shirt??
Humbly resolves#54752.
Track whether module declarations are inline (fixes#12590)
To track whether module declarations are inline I added a field `inline: bool` to `ast::Mod`. The main use case is for pretty to know whether it should render the items associated with the module, but perhaps there are use cases for this information to not be forgotten in the AST.
Remove OneVector, increase related SmallVec capacities
Removes the `OneVector` type alias (equivalent to `SmallVec<[T; 1]>`); it is used in scenarios where the capacity of 1 is often exceeded, which might be nullifying the performance wins (due to spilling to the heap) expected when using `SmallVec` instead of `Vec`.
The numbers I used in this PR are very rough estimates - it would probably be a good idea to adjust some/all of them, which is what this proposal is all about.
It might be a good idea to additionally create some local type aliases for the `SmallVec`s in the `Folder` trait, as they are repeated in quite a few spots; I'd be happy to apply this sort of adjustments.
Stabilize pattern_parentheses feature
Addresses #51087 .
Stabilizes the previously unstable feature `pattern_parentheses` which enables the use of `()` in match patterns.
`impl trait` in bindings (feature: impl-trait-existential-types)
This PR enables `impl Trait` syntax (opaque types) to be used in bindings, e.g.
* `let foo: impl Clone = 1;`
* `static foo: impl Clone = 2;`
* `const foo: impl Clone = 3;`
This is part of [RFC 2071](https://github.com/rust-lang/rfcs/blob/master/text/2071-impl-trait-existential-types.md) ([tracking issue](https://github.com/rust-lang/rust/issues/34511)), but exists behind the separate feature gate `impl_trait_in_bindings`.
CC @cramertj @oli-obk @eddyb @Centril @varkor
Support an explicit annotation for marker traits
From the tracking issue for rust-lang/rfcs#1268:
> It seems obvious that we should make a `#[marker]` annotation. ~ https://github.com/rust-lang/rust/issues/29864#issuecomment-368959441
This PR allows you to put `#[marker]` on a trait, at which point:
- [x] The trait must not have any items ~~All of the trait's items must have defaults~~
- [x] Any impl of the trait must be empty (not override any items)
- [x] But impls of the trait are allowed to overlap
r? @nikomatsakis
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.
This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.
I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.
r? @alexcrichton
Rollup of 16 pull requests
Successful merges:
- #53652 (define copy_within on slices)
- #54261 (Make `dyn` a keyword in the 2018 edition)
- #54280 (remove (more) CAS API from Atomic* types where not natively supported)
- #54323 (rustbuild: drop color handling)
- #54350 (Support specifying edition in doc test)
- #54370 (Improve handling of type bounds in `bit_set.rs`.)
- #54371 (add -Zui-testing to rustdoc)
- #54374 (Make 'proc_macro::MultiSpan' public.)
- #54402 (Use no_default_libraries for all NetBSD flavors)
- #54409 (Detect `for _ in in bar {}` typo)
- #54412 (add applicability to span_suggestion call)
- #54413 (Add UI test for deref recursion limit printing twice)
- #54415 (parser: Tweak function parameter parsing to avoid rollback on succesfull path)
- #54420 (Compress `Liveness` data some more.)
- #54422 (Simplify slice's first(_mut) and last(_mut) with get)
- #54446 (Unify christianpoveda's emails)
Failed merges:
- #54058 (Introduce the partition_dedup/by/by_key methods for slices)
r? @ghost
parser: Tweak function parameter parsing to avoid rollback on succesfull path
Since rollback is not perfect and may e.g. leave non-fatal errors after it, we need to make sure compilation fails if it happens.
So in particular case of `fn parse_arg_general` we need to parse the "good" `TYPE` first and only then rollback and recover erroneous `PAT: TYPE` if necessary.
Found when working on https://github.com/rust-lang/rfcs/pull/2544#issuecomment-423293222.
r? @ghost
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
Issue 54246
I added the option of providing a help message for deprecated features, that takes precedence over the default `help: remove this attribute` message, along with messages for the features that mention replacements in the reason for deprecation.
Fixes#54246.
Merge `bitvec.rs` and `indexed_set.rs`
Because it's not good to have two separate implementations. Also, I will combine the best parts of each to improve NLL memory usage on some benchmarks significantly.
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.
This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs --> bit_set.rs
- indexed_set.rs --> (removed)
- BitArray + IdxSet --> BitSet (merged, see below)
- BitVector --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix --> BitMatrix
- SparseBitMatrix --> SparseBitMatrix
The changes within the bitset types themselves are as follows.
```
OLD OLD NEW
BitArray<C> IdxSet<T> BitSet<T>
-------- ------ ------
grow - grow
new - (remove)
new_empty new_empty new_empty
new_filled new_filled new_filled
- to_hybrid to_hybrid
clear clear clear
set_up_to set_up_to set_up_to
clear_above - clear_above
count - count
contains(T) contains(&T) contains(T)
contains_all - superset
is_empty - is_empty
insert(T) add(&T) insert(T)
insert_all - insert_all()
remove(T) remove(&T) remove(T)
words words words
words_mut words_mut words_mut
- overwrite overwrite
merge union union
- subtract subtract
- intersect intersect
iter iter iter
```
In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
`insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
over `contains_all`, `domain_size` over `num_bits`).
Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
Temporarily prohibit proc macro attributes placed after derives
... and also proc macro attributes used together with `#[test]`/`#[bench]`.
Addresses item 6 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393.
The end goal is straightforward predictable left-to-right expansion order for attributes.
Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order.
I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal.
How to fix broken code (derives):
- Move macro attributes above derives. This won't change expansion order, they are expanded before derives anyway.
Using attribute macros on same items with `#[test]` and `#[bench]` is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives.
How to fix broken code (test/bench):
- Enable `#![feature(plugin)]` (don't ask why).
r? @ghost
Note it requires MIR-borrowck to be enabled to actually do anything.
Note also that it implicitly turns off our AST-based check for
mutation in guards.
Rollup of 11 pull requests
Successful merges:
- #53371 (Do not emit E0277 on incorrect tuple destructured binding)
- #53829 (Add rustc SHA to released DWARF debuginfo)
- #53950 (Allow for opting out of ThinLTO and clean up LTO related cli flag handling.)
- #53976 (Replace unwrap calls in example by expect)
- #54070 (Add Error::description soft-deprecation to RELEASES)
- #54076 (miri loop detector hashing)
- #54119 (Add some unit tests for find_best_match_for_name)
- #54147 (Add a test that tries to modify static memory at compile-time)
- #54150 (Updated 1.29 release notes with --document-private-items flag)
- #54163 (Update stage 0 to latest beta)
- #54170 (COMPILER_TESTS.md has been moved)
Add some unit tests for find_best_match_for_name
There were only some UI tests that covered this function.
Since there's more diagnostic work going on, I think it makes
sense to have this unit tested.
