Auto merge of #60377 - Centril:rollup-42fxe9u, r=Centril
Rollup of 9 pull requests
Successful merges:
- #59946 (Fix equivalent string in escape_default docs)
- #60256 (Option::flatten)
- #60305 (hir: remove LoweredNodeId)
- #60334 (Stabilized vectored IO)
- #60353 (Add test not to forget resolved ICE)
- #60356 (Stabilize str::as_mut_ptr)
- #60358 (Clarify the short explanation of E0207)
- #60359 (resolve: Consider erroneous imports used to avoid duplicate diagnostics)
- #60360 (Add test case for labeled break in const assignment)
Rollup merge of #60358 - nickolay:patch-1, r=GuillaumeGomez
Clarify the short explanation of E0207
After being greatly improved in #33692, https://doc.rust-lang.org/error-index.html#E0207 uses terminology from the related RFC, which is different from the [reference](https://doc.rust-lang.org/reference/items/implementations.html), e.g. "self type" instead of "implementing type" and "trait reference" instead of "implemented trait".
It probably makes no difference to an experienced reader, but for a newbie like me it added to the confusion as you can't look up the definition of the terms being used and can't be sure you've guessed correctly...
I would also move the link to RFC to the top, as it seems to be the only doc that attempts to explain what the third criteria entails), but it seems to go against the accepted style.
Rollup merge of #60334 - sfackler:stable-iovec, r=alexcrichton
Stabilized vectored IO
This renames `std::io::IoVec` to `std::io::IoSlice` and
`std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes
`std::io::IoSlice`, `std::io::IoSliceMut`,
`std::io::Read::read_vectored`, and `std::io::Write::write_vectored`.
Rollup merge of #60270 - alexcrichton:metadata-multi-cgu, r=oli-obk
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!
Rollup merge of #60022 - nathankleyn:fix-issue-59543, r=Centril
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.
Auto merge of #60346 - dima74:patch-1, r=GuillaumeGomez
Fix default value for setting "Auto-hide item methods' documentation"
If I open any documentation page in incognito mode (for example [for `Option` enum](https://doc.rust-lang.org/nightly/std/option/enum.Option.html)), then methods will be collapsed, though [on the settings page](https://doc.rust-lang.org/nightly/settings.html) there will be displayed that "Auto-hide item methods' documentation" option is disabled.
If I understand correctly, property "Auto-hide item methods' documentation" [should be disabled by default](https://github.com/rust-lang/rust/blob/938d4ffe16c4430e1dcede570b06227114cb73d5/src/librustdoc/html/render.rs#L1969), so correct check would be `property === "true"`. This is consistent with other options:
Options which are enabled by default are compared to `"false"`
Steven Fackler [Sat, 27 Apr 2019 15:34:08 +0000 (08:34 -0700)]
Stabilized vectored IO
This renames `std::io::IoVec` to `std::io::IoSlice` and
`std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes
`std::io::IoSlice`, `std::io::IoSliceMut`,
`std::io::Read::read_vectored`, and `std::io::Write::write_vectored`.
Auto merge of #60329 - Centril:rollup-wv8g1ex, r=Centril
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)
Rollup merge of #60292 - varkor:ty-tuple-substs, r=nikomatsakis
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.
Auto merge of #59887 - eddyb:safer-metadata, r=Zoxc
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.
Auto merge of #60167 - varkor:tidy-filelength, r=matthewjasper
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).
Auto merge of #60296 - Centril:rollup-qh9la7k, r=Centril
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)
Rollup merge of #60284 - varkor:const-param-of-type-param, r=cramertj
Do not allow const generics to depend on type parameters
Fixes https://github.com/rust-lang/rust/issues/60264. In https://github.com/rust-lang/rust/pull/58191/files/b534cf992d0189032207f395c27ed092c89b40c7#diff-aeb0880081a991f34aef2ab889e1fb7a, it was suggested that there might be a better place for this error, but as this bug already affects stable, it's probably worth merging this now, and refactoring afterwards (I can open an issue for this).
Rollup merge of #60225 - Centril:hir-exprkind-use-in-for-loops, r=oli-obk
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 https://github.com/rust-lang/rust/pull/59288/commits/91b0abdfb23f980d2e5d5c30bc65ed8e95b04788 from https://github.com/rust-lang/rust/pull/59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
Rollup merge of #60165 - Nemo157:pin-into-inner, r=cramertj
Add Pin::{into_inner,into_inner_unchecked}
These functions are useful for unsafe code that needs to temporarily pull smart pointers out of the `Pin`, e.g. [the change that inspired them](https://github.com/Nemo157/futures-rs/commit/b4361780faf764c7cb046ed75f863a6fcfd44800#diff-1a4e0ba4d1b539412ca576411ec6c7c2R258) is taking a `Pin<Box<dyn Future>>`, turning it into a `*mut dyn Future` via `Box::into_raw(unsafe { Pin::into_inner_unchecked(pin) })` then later dropping this via `drop(Pin::from(Box::from_raw(ptr)))`. This can be accomplished today via `{ let ptr = unsafe { Pin::get_unchecked_mut(pin.as_mut()) } as *mut dyn Future; mem::forget(pin); ptr }`, but this is far more complicated and loses out on the symmetry of using `Box::into_raw` and `Box::from_raw`.
I'll extend the documentation on what guarantees `into_inner_unchecked` needs to uphold once I get some feedback on whether this API is wanted or not.
projects / rust.git / log