Float 'incomplete_features' out to a const for visibility
Float `let incomplete_features` out to a `const INCOMPLETE_FEATURES` and colocate near `active` features so that it is easier to find and edit.
r? @oli-obk
(use rollup)
rustc: Flag metadata compatible with multiple CGUs
It looks like the `OutputType::Metadata` kind in the compiler was
misclassified in #38571 long ago by accident as incompatible with
codegen units and a single output file. This means that if you emit both
a linkable artifact and metadata it silently turns off multiple codegen
units unintentionally!
This commit corrects the situation to ensure that if `--emit metadata`
is used it doesn't implicitly disable multiple codegen units. This will
ensure we don't accidentally regress compiler performance when striving
to implement pipelined compilation!
Document `Item` type in `std::env::SplitPaths` iterator.
Previously there wasn't any documentation to show what the type of
`Item` was inside `std::env::SplitPaths`. Now, in the same format as
other examples of docs in `std` for `Iterator#Item`, we mention the
type.
This fixes#59543.
r? @steveklabnik
Rollup of 5 pull requests
Successful merges:
- #60292 (Replace the `&'tcx List<Ty<'tcx>>` in `TyKind::Tuple` with `SubstsRef<'tcx>`)
- #60307 (Make "Implementations on Foreign Types" items in sidebar link to specific impls)
- #60309 (Add 1.34.1 release notes)
- #60315 (bootstrap: use correct version numbers for llvm-tools and lldb)
- #60316 (Use "capacity" as parameter name in with_capacity() methods)
Failed merges:
r? @ghost
Use "capacity" as parameter name in with_capacity() methods
See #60271.
The only place where I didn't change the parameter name is `RawVec`. The problem is that it has a `.cap()` method instead of the usual `.capacity()`:
597f432489/src/liballoc/raw_vec.rs (L200-L210)
Changing this would be a breaking change, and I guess that's not worth it.
But since I didn't change `.cap()` there, I didn't change the `cap` parameter name to `capacity`, either.
bootstrap: use correct version numbers for llvm-tools and lldb
The current URLs for the `llvm-tools` and `lldb` components are a bit broken right now:
```
https://static.rust-lang.org/dist/2019-04-25/llvm-tools-1.34.1 (fc50f328b 2019-04-24)-aarch64-unknown-linux-gnu.tar.gz
```
This PR uses proper version numbers for those. Tested a dist build locally and everything works.
r? @Mark-Simulacrum
Make "Implementations on Foreign Types" items in sidebar link to specific impls
This solves #56018 for most cases (though not work for foreign impls with same names)
Replace the `&'tcx List<Ty<'tcx>>` in `TyKind::Tuple` with `SubstsRef<'tcx>`
Part of the suggested refactoring for https://github.com/rust-lang/rust/issues/42340. As expected, this is a little messy, because there are many places that the components of tuples are expected to be types, rather than arbitrary kinds. However, it should open up the way for a refactoring of `TyS` itself.
r? @nikomatsakis
rustc_metadata: more safely read/write the index positions.
This is a small part of a larger refactor, that I want to benchmark independently.
The final code would be even cleaner than this, so this is sort of an "worst case" test.
Bootstrap x86_64 musl by itself
It should slightly reduce build time and prepares ground for musl native tests.
NOTE: I haven't tested artifacts yet (only the build).
Can I have double try?
r? @alexcrichton
Add a tidy check for files with over 3,000 lines
Files with a large number of lines can cause issues in GitHub (e.g. https://github.com/rust-lang/rust/issues/60015) and also tend to be indicative of opportunities to refactor into less monolithic structures.
This adds a new check to tidy to warn against files that have more than 3,000 lines, as suggested in https://github.com/rust-lang/rust/issues/60015#issuecomment-483868594. (This number was chosen fairly arbitrarily as a reasonable indicator of size.) This check can be ignored with `// ignore-tidy-filelength`.
Existing files with greater than 3,000 lines currently ignore the check, but this helps us spot when files are getting too large. (We might try to split up all files larger than this in the future, as in https://github.com/rust-lang/rust/issues/60015).
Rollup of 12 pull requests
Successful merges:
- #59734 (Prevent failure in case no space left on device in rustdoc)
- #59940 (Set cfg(test) when rustdoc is running with --test option)
- #60134 (Fix index-page generation)
- #60165 (Add Pin::{into_inner,into_inner_unchecked})
- #60183 (Chalkify: Add builtin Copy/Clone)
- #60225 (Introduce hir::ExprKind::Use and employ in for loop desugaring.)
- #60247 (Implement Debug for Place using Place::iterate)
- #60259 (Derive Default instead of new in applicable lint)
- #60267 (Add feature-gate for f16c target feature)
- #60284 (Do not allow const generics to depend on type parameters)
- #60285 (Do not ICE when checking types against foreign fn)
- #60289 (Make `-Z allow-features` work for stdlib features)
Failed merges:
r? @ghost
Derive Default instead of new in applicable lint
Closes#60181
As far as I can see, at least within the `src/librustc_lint` directory this is the only place this is applicable.
Introduce hir::ExprKind::Use and employ in for loop desugaring.
In the `for $pat in $expr $block` desugaring we end with a `{ let _result = $match_expr; _result }` construct which makes `for` loops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in https://github.com/rust-lang/rust/pull/21984.
This PR replaces the construct with `hir::ExprKind::Use(P<hir::Expr>)` which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).
This is extracted out of 91b0abdfb2 from https://github.com/rust-lang/rust/pull/59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
r? @oli-obk
