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
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](b4361780fa (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.
r? @withoutboats
Fix index-page generation
Fixes#60096.
The minifier was minifying crates name in `searchIndex` key position, which was a bit problematic for multiple reasons.
r? @rust-lang/rustdoc
Set cfg(test) when rustdoc is running with --test option
Following a [discussion on twitter](https://twitter.com/burntsushi5/status/1117091914199785473), I proposed this change. What do you think about it?
r? @QuietMisdreavus
cc @BurntSushi
Improved error message when type must be bound due to generator.
Fixes#58930.
Keen to get some feedback - is this as minimal as we can get it or is there an existing visitor I could repurpose?
Implement saturating_abs() and saturating_neg() functions for signed integer types
Similar to wrapping_abs() / wrapping_neg() functions but saturating at the numeric bounds instead of wrapping around. Complements the existing set of functions with saturation mechanics.
cc #59983
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!
Similar to wrapping_abs() / wrapping_neg() functions but saturating at
the numeric bounds instead of wrapping around. Complements the existing
set of functions with saturation mechanics.
submodules: update clippy from 9897442f to 8c0e038f
Should fix clippy/rls toolstate breakage
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
r? @oli-obk
Changes:
````
Rustup for https://github.com/rust-lang/rust/pull/59042
Update pulldown_cmark to 0.5
Only run AppVeyor on r+, try and the master branch
Remove approx_constant known problems
Suppress let_and_return if let has attributes
Add test for or_fun_call macro suggestion
UI test cleanup: Extract needless_range_loop tests
Change "if types change" to "if you later change the type"
````
