Get back the more precise suggestion spans of old regionck
I noticed that when you turn on nll, the structured suggestion replaces a snippet instead of appending a snippet. It seems clearer to the user to only highlight the newly added characters instead of the entire `impl Trait` (and old regionck already does it this way).
r? ``@estebank``
Update all submodules that rustbuild doesn't depend on lazily
This only updates the submodules the first time they're needed, instead
of unconditionally the first time you run x.py.
Ideally, this would move *all* submodules to rustbuild and not exclude some tools and
backtrace. Unfortunately, cargo requires all `Cargo.toml` files in the
whole workspace to be present to build any crate.
On my machine, this takes the time for an initial submodule clone (for
`x.py --help`) from 55.70 to 15.87 seconds.
Helps with https://github.com/rust-lang/rust/issues/76653. Builds on https://github.com/rust-lang/rust/pull/86015 and should not be merged before (only the last commit is relevant).
This only updates the submodules the first time they're needed, instead
of unconditionally the first time you run x.py.
Ideally, this would move *all* submodules and not exclude some tools and
backtrace. Unfortunately, cargo requires all `Cargo.toml` files in the
whole workspace to be present to build any crate.
On my machine, this takes the time for an initial submodule clone (for
`x.py --help`) from 55.70 to 15.87 seconds.
This uses exactly the same logic as the LLVM update used, modulo some
minor cleanups:
- Use a local variable for `src.join(relative_path)`
- Remove unnecessary arrays for `book!` macro and make the macro simpler to use
- Add more comments
Update books
## reference
6 commits in ab60513a3a5a0591e237fddff5d027a982648392..82d75cf423e4a7824fb36e73ccb18519d6900610
2021-07-05 08:27:31 -0700 to 2021-07-15 06:49:08 -0700
- fix wording/punctuation in "Lifetime bounds" (rust-lang/reference#1062)
- mention implicit `Sized` bound in more places (rust-lang/reference#1053)
- (rust-lang/reference#1060)
- Remove inner attributes from non-block expressions. (rust-lang/reference#1051)
- Add note about the sign of the remainder (rust-lang/reference#1073)
- Clarify closure capture modes slightly (rust-lang/reference#1064)
## book
21 commits in a90f07f1e9a7fc75dc9105a6c6f16d5c13edceb0..eac55314210519238652f12b30fec9daea61f7fe
2021-07-05 14:43:12 -0400 to 2021-07-19 11:08:01 -0400
- (rust-lang/book#2791)
- Add Deref trait to overload the deref operator in appendix table
- Revise linker installation instructions. Fixesrust-lang/book#2151.
- Clarify number literal type suffixes. Fixesrust-lang/book#1979.
- Add a note that lifetimes are coming up but aren't required
- Zip creates an iterator, not a vector. Fixesrust-lang/book#2762.
- Add Thai translation to the appendix. Connects to rust-lang/book#2636
- Derive Copy and Clone for Point to match stdlib docs example; fixesrust-lang/book#2657
- Make the definition of Option match the stdlib's, fixesrust-lang/book#2634
- Explain double quote backslash; closesrust-lang/book#2597
- Don't use the term 'anonymous struct' to fixrust-lang/book#2584
- Reword a sentence to fixrust-lang/book#2525
- Add Hindi translation. Connects to rust-lang/book#2496
- Remove unsafe Ferris designations from code. Fixesrust-lang/book#2555
- Add Traditional Chinese translation. Connects to rust-lang/book#2470
- Remove some more references to the authors field
- Make Appendix E be a link
- fix line wrapping
- remove description about the authors field
- remove the authors field
- remove the authors field
## rust-by-example
6 commits in 028f93a61500fe8f746ee7cc6b204ea6c9f42935..1db6bb483cc87ad3b424d9aba764fe622960a1be
2021-07-06 06:28:53 -0300 to 2021-07-15 06:17:42 -0300
- Updated the file destructure_tuple.md (rust-lang/rust-by-example#1452)
- Fix nomenclature around methods (rust-lang/rust-by-example#1450)
- std_misc/path.md: update `Show` to `Display` (rust-lang/rust-by-example#1449)
- Fix up github action (rust-lang/rust-by-example#1451)
- Remove github pages
- Support GitHub Actions (rust-lang/rust-by-example#1330)
## rustc-dev-guide
2 commits in 60e282559104035985331645907c3d9f842312c5..93422c21baca585dc88357ec886a48f6ddc7d665
2021-07-05 11:21:03 -0400 to 2021-07-13 12:45:58 -0400
- Update for merge of CrateDisambiguator into StableCrateId
- Minor capitalization fix (rust-lang/rustc-dev-guide#1170)
## edition-guide
8 commits in 5d57b3832f8d308a9f478ce0a69799548f27ad4d..af696ce8ea526445590ae0ca66a8128d2a95a69a
2021-07-05 10:33:32 +0200 to 2021-07-20 11:38:03 -0400
- Add migration section for panic-macro-consistency (rust-lang/edition-guide#258)
- Update transitioning chapter. (rust-lang/edition-guide#255)
- Add details on migrating the Cargo feature resolver. (rust-lang/edition-guide#259)
- Improve panic macro consistency summary (rust-lang/edition-guide#256)
- Add migration details to or-patterns guide (rust-lang/edition-guide#252)
- Add migration section to into-iterator (rust-lang/edition-guide#253)
- Add Rust 2021 prelude migration details (rust-lang/edition-guide#251)
- Provide more information about disjoint capture in closures and migration instructions (rust-lang/edition-guide#246)
## embedded-book
1 commits in 506840eb73b0749336e1d5274e16d6393892ee82..09986cd352404eb4659db44613b27cac9aa652fc
2021-06-24 00:01:32 +0000 to 2021-07-18 19:26:46 +0000
- Stop referring to the alloc crate as unstable (rust-embedded/book#297)
Better diagnostics with mismatched types due to implicit static lifetime
Fixes#78113
I think this is my first diagnostics PR...definitely happy to hear thoughts on the direction/implementation here.
I was originally just trying to solve the error above, where the lifetime on a GAT was causing a cryptic "mismatched types" error. But as I was writing this, I realized that this (unintentionally) also applied to a different case: `wf-in-foreign-fn-decls-issue-80468.rs`. I'm not sure if this diagnostic should get a new error code, or even reuse an existing one. And, there might be some ways to make this even more generalized. Also, the error is a bit more lengthy and verbose than probably needed. So thoughts there are welcome too.
This PR essentially ended up adding a new nice region error pass that triggers if a type doesn't match the self type of an impl which is selected because of a predicate because of an implicit static bound on that self type.
r? `@estebank`
Remove special case for `ExprKind::Paren` in `MutVisitor`
The special case breaks several useful invariants (`ExpnId`s are
globally unique, and never change). This special case
was added back in 2016 in https://github.com/rust-lang/rust/pull/34355
r? `@petrochenkov`
The special case breaks several useful invariants (`ExpnId`s are
globally unique, and never change). This special case
was added back in 2016 in https://github.com/rust-lang/rust/pull/34355
[debuginfo] Emit associated type bindings in trait object type names.
This PR updates debuginfo type name generation for trait objects to include associated type bindings and auto trait bounds -- so that, for example, the debuginfo type name of `&dyn Iterator<Item=Foo>` and `&dyn Iterator<Item=Bar>` don't both map to just `&dyn Iterator` anymore.
The following table shows examples of debuginfo type names before and after the PR:
| type | before | after |
|------|---------|-------|
| `&dyn Iterator<Item=u32>>` | `&dyn Iterator` | `&dyn Iterator<Item=u32>` |
| `&(dyn Iterator<Item=u32>> + Sync)` | `&dyn Iterator` | `&(dyn Iterator<Item=u32> + Sync)` |
| `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `&dyn SomeTrait<bool, i8>` | `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` |
For targets that need C++-like type names, we use `assoc$<Item,u32>` instead of `Item=u32`:
| type | before | after |
|------|---------|-------|
| `&dyn Iterator<Item=u32>>` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> > > >` |
| `&(dyn Iterator<Item=u32>> + Sync)` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> >,Sync> >` |
| `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `ref$<dyn$<SomeTrait<bool, i8> > >` | `ref$<dyn$<SomeTrait<bool,i8,assoc$<Bar,u32> > >,Send> >` |
The PR also adds self-profiling measurements for debuginfo type name generation (re. https://github.com/rust-lang/rust/issues/86431). It looks like the compiler spends up to 0.5% of its time in that task, so the potential for optimizing it via caching seems limited.
However, the perf run also shows [the biggest regression](https://perf.rust-lang.org/detailed-query.html?commit=585e91c718b0b2c5319e1fffd0ff1e62aaf7ccc2&base_commit=b9197978a90be6f7570741eabe2da175fec75375&benchmark=tokio-webpush-simple-debug&run_name=incr-unchanged) in a test case that does not even invoke the code in question. This suggests that the length of the names we generate here can affect performance by influencing how much data the linker has to copy around.
Fixes https://github.com/rust-lang/rust/issues/86134.
Various diagnostics clean ups/tweaks
* Always point at macros, including derive macros
* Point at non-local items that introduce a trait requirement
* On private associated item, point at definition
Update Clippy
This is an out-of-cycle Clippy update, to fix 3 ICEs before the release (This should be merged before beta is branched):
rust-lang/rust-clippy#7470
rust-lang/rust-clippy#7471
rust-lang/rust-clippy#7473
cc `@jackh726` `@JohnTitor` rust-lang/rust-clippy#7470 was caused by #86867. I saw the same ICE in the last rustup for Clippy though, so this might be a more general problem. Is there something we should check before calling `layout_of`? Should we always check for `ty.has_escaping_bound_vars()` before calling `layout_of`? Or is this overkill?
r? `@Manishearth`
* Always point at macros, including derive macros
* Point at non-local items that introduce a trait requirement
* On private associated item, point at definition
Make `--force-warns` a normal lint level option
Now that `ForceWarn` is a lint level, there's no reason `--force-warns` should be treated differently from other options that set lint levels. This merges the `ForceWarn` handling in with the other lint level command line options. It also unifies all of the relevant selection logic in `compiler/rustc_lint/src/levels.rs`, rather than having some of it weirdly elsewhere.
Fixes#86958, which arose from the special-cased handling of `ForceWarn` having had an error in it.
Add --nocapture option to rustdoc
Fixes https://github.com/rust-lang/rust/issues/26309.
Fixes#45724.
Once this PR is merged, I'll send a PR to cargo to also pass `--nocapture` to rustdoc.
cc `@jyn514`
r? `@camelid`
Compute a better `lint_node_id` during expansion
When we need to emit a lint at a macro invocation, we currently use the
`NodeId` of its parent definition (e.g. the enclosing function). This
means that any `#[allow]` / `#[deny]` attributes placed 'closer' to the
macro (e.g. on an enclosing block or statement) will have no effect.
This commit computes a better `lint_node_id` in `InvocationCollector`.
When we visit/flat_map an AST node, we assign it a `NodeId` (earlier
than we normally would), and store than `NodeId` in current
`ExpansionData`. When we collect a macro invocation, the current
`lint_node_id` gets cloned along with our `ExpansionData`, allowing it
to be used if we need to emit a lint later on.
This improves the handling of `#[allow]` / `#[deny]` for
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` and some `asm!`-related lints.
The 'legacy derive helpers' lint retains its current behavior
(I've inlined the now-removed `lint_node_id` function), since
there isn't an `ExpansionData` readily available.
feat(rustc_lint): add `dyn_drop`
Based on the conversation in #86747.
Explanation
-----------
A trait object bound of the form `dyn Drop` is most likely misleading and not what the programmer intended.
`Drop` bounds do not actually indicate whether a type can be trivially dropped or not, because a composite type containing `Drop` types does not necessarily implement `Drop` itself. Naïvely, one might be tempted to write a deferred drop system, to pull cleaning up memory out of a latency-sensitive code path, using `dyn Drop` trait objects. However, this breaks down e.g. when `T` is `String`, which does not implement `Drop`, but should probably be accepted.
To write a trait object bound that accepts anything, use a placeholder trait with a blanket implementation.
```rust
trait Placeholder {}
impl<T> Placeholder for T {}
fn foo(_x: Box<dyn Placeholder>) {}
```
Use existing declaration of rust_eh_personality
If crate declares `rust_eh_personality`, re-use existing declaration
as otherwise attempts to set function attributes that follow the
declaration will fail (unless it happens to have exactly the same
type signature as the one predefined in the compiler).
Fixes#70117.
Fixes https://github.com/rust-lang/rust/pull/81469#issuecomment-809428126; probably.
These are all testing corner-cases in the compiler.
Adding a new warning broke these test cases, but --cap-lints stops
it from actually breaking things in production.
Based on the conversation in #86747.
Explanation
-----------
A trait object bound of the form `dyn Drop` is most likely misleading
and not what the programmer intended.
`Drop` bounds do not actually indicate whether a type can be trivially
dropped or not, because a composite type containing `Drop` types does
not necessarily implement `Drop` itself. Naïvely, one might be tempted
to write a deferred drop system, to pull cleaning up memory out of a
latency-sensitive code path, using `dyn Drop` trait objects. However,
this breaks down e.g. when `T` is `String`, which does not implement
`Drop`, but should probably be accepted.
To write a trait object bound that accepts anything, use a placeholder
trait with a blanket implementation.
```rust
trait Placeholder {}
impl<T> Placeholder for T {}
fn foo(_x: Box<dyn Placeholder>) {}
```
