bors [Tue, 10 May 2022 03:11:05 +0000 (03:11 +0000)]
Auto merge of #96803 - jyn514:faster-assemble, r=Mark-Simulacrum
Make "Assemble stage1 compiler" orders of magnitude faster
This used to take upwards of 5 seconds for me locally. I found that the culprit was copying the downloaded LLVM shared object:
```
[22:28:03] Install "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so" to "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libLLVM-14-rust-1.62.0-nightly.so"
[22:28:09] c Sysroot { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) } }
```
It turned out that `install()` used full copies unconditionally. Change it to try using a hard-link before falling back to copying.
Since https://github.com/rust-lang/rust/pull/93803, when listing all bounds and predicates we now need to account for the possible presence of predicates on any of the generic parameters. Both bugs were hidden by the special handling of bounds at the generic parameter declaration position.
Trait alias expansion used to confuse predicates on `Self` and where predicates.
Exiting too late when listing all the bounds caused a cycle error.
bors [Mon, 9 May 2022 22:15:30 +0000 (22:15 +0000)]
Auto merge of #96838 - tmiasko:lazy-switch-sources, r=oli-obk
Optimize switch sources representation and usage
* Avoid constructing switch sources unless necessary - switch sources are used by backward analysis with a custom switch int edge effects, but are otherwise unnecessarily computed.
* Use sparse representation of switch sources to avoid quadratic space overhead.
Matthias Krüger [Mon, 9 May 2022 16:45:39 +0000 (18:45 +0200)]
Rollup merge of #96854 - jackh726:subst-cleanup, r=compiler-errors
Some subst cleanup
Two separate things here. Both changes are useful for some refactoring I'm doing to add an "EarlyBinder" newtype. (Part of chalkification).
1) Remove `subst_spanned` and just use `subst`. It wasn't used much anyways. In practice, I think we can probably get most of the info just from the actual error message. If not, outputting logs should do the trick. (The specific line probably wouldn't help much anyways).
2) Call `.subst()` before `replace_bound_vars_with_fresh_vars` and `erase_late_bound_regions` in three places that do the opposite. I think there might have been some time in the past that the order here matter for something, but this shouldn't be the case anymore. Conceptually, it makes more sense to the of the *early bound* vars on `fn`s as "outside" the late bound vars.
Matthias Krüger [Mon, 9 May 2022 16:45:37 +0000 (18:45 +0200)]
Rollup merge of #96841 - thomcc:revert-osstr-join, r=m-ou-se
Revert "Implement [OsStr]::join", which was merged without FCP.
This reverts commit 4fcbc53820ab423bbeb41f07822369aa05da1d68, see https://github.com/rust-lang/rust/pull/96744. (I'm terribly sorry, and truly don't remember r+ing it, or even having seen it before yesterday, which is... genuinely very worrisome for me).
Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted:
```rust
pub trait Tr { fn f(); }
pub struct Ty;
impl Tr for Ty { #[doc(hidden)] fn f() {} }
// ^^^^^^^^^^^^^^ ignored by rustdoc and currently
// no error or warning issued
```
This may lead users to the wrong belief that the attribute has an effect. In fact, several such cases are found in the standard library (I've removed all of them in this PR).
There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page.
This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning.
Matthias Krüger [Mon, 9 May 2022 16:45:35 +0000 (18:45 +0200)]
Rollup merge of #95483 - golddranks:improve_float_docs, r=joshtriplett
Improve floating point documentation
This is my attempt to improve/solve https://github.com/rust-lang/rust/issues/95468 and https://github.com/rust-lang/rust/issues/73328 .
Added/refined explanations:
- Refine the "NaN as a special value" top level explanation of f32
- Refine `const NAN` docstring: add an explanation about there being multitude of NaN bitpatterns and disclaimer about the portability/stability guarantees.
- Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings: add disclaimer about the sign bit of NaNs.
- Refine `fn min` and `fn max` docstrings: explain the semantics and their relationship to the standard and libm better.
- Refine `fn trunc` docstrings: explain the semantics slightly more.
- Refine `fn powi` docstrings: add disclaimer that the rounding behaviour might be different from `powf`.
- Refine `fn copysign` docstrings: add disclaimer about payloads of NaNs.
- Refine `minimum` and `maximum`: add disclaimer that "propagating NaN" doesn't mean that propagating the NaN bit patterns is guaranteed.
- Refine `max` and `min` docstrings: add "ignoring NaN" to bring the one-row explanation to parity with `minimum` and `maximum`.
Cosmetic changes:
- Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`.
- Reword "a number" to `self` in function docstrings to clarify.
- Remove "Returns NAN if the number is NAN" from `abs`, as this is told to be the default behavior in the top explanation.
bors [Mon, 9 May 2022 11:49:09 +0000 (11:49 +0000)]
Auto merge of #96815 - SparrowLii:promote_const, r=oli-obk
optimize `promote_consts` by caching the results of `validate_local`
From the FIXME in the impl of `promote_consts`. Early return the `validate_local` should save some compile time.
`qualif_local` is similar to this, but requires futher changing because there are different types of qualif checks. If this PR is effective, I will do it as well.
bors [Mon, 9 May 2022 04:47:30 +0000 (04:47 +0000)]
Auto merge of #95960 - jhpratt:remove-rustc_deprecated, r=compiler-errors
Remove `#[rustc_deprecated]`
This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958, which includes converting `stdarch`.
I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics, as they're only intended to be short-term.
Joshua Nelson [Sat, 7 May 2022 03:42:36 +0000 (22:42 -0500)]
Make "Assemble stage1 compiler" orders of magnitude faster
This used to take upwards of 5 seconds for me locally. I found that the culprit was copying the downloaded LLVM shared object:
```
[22:28:03] Install "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so" to "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libLLVM-14-rust-1.62.0-nightly.so"
[22:28:09] c Sysroot { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) } }
```
It turned out that `install()` used full copies unconditionally. Change it to try using a hard-link before falling back to copying.
bors [Mon, 9 May 2022 00:02:55 +0000 (00:02 +0000)]
Auto merge of #95542 - xFrednet:rfc-2383-expect-query, r=wesleywiser
Support tool lints with the `#[expect]` attribute (RFC 2383)
This PR fixes the ICE https://github.com/rust-lang/rust/issues/94953 by making the assert for converted expectation IDs conditional.
Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.
The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. :sauropod:
bors [Sun, 8 May 2022 14:10:12 +0000 (14:10 +0000)]
Auto merge of #96770 - flip1995:fix-trait-type-in-bounds, r=cjgillot
Track if a where bound comes from a impl Trait desugar
With https://github.com/rust-lang/rust/pull/93803 `impl Trait` function arguments get desugared to hidden where bounds. However, Clippy needs to know if a bound was originally a `impl Trait` or an actual bound. This adds a field to the `WhereBoundPredicate` struct to keep track of this information during AST->HIR lowering.
bors [Sun, 8 May 2022 08:45:20 +0000 (08:45 +0000)]
Auto merge of #96659 - thatzopoulos:issue-90679-fix, r=Mark-Simulacrum
Improve error for missing cmake
This PR updates the error message for a missing `cmake` to be more in line with the error message for a missing installation of `ninja`.
The original issue, (#90679), suggests that both `ninja` and `cmake` are only needed for building LLVM, so I have included the suggestion from `ninja` to set `download-ci-llvm = true` if the user would rather download LLVM. If `cmake` actually is used in other areas, I can remove that part of the message.
bors [Sun, 8 May 2022 00:57:08 +0000 (00:57 +0000)]
Auto merge of #94206 - PrestonFrom:significant_drop, r=flip1995
Create clippy lint against unexpectedly late drop for temporaries in match scrutinee expressions
A new clippy lint for issue 93883 (https://github.com/rust-lang/rust/issues/93883). Relies on a new trait in `marker` (called `SignificantDrop` to enable linting), which is why this PR is for the rust-lang repo and not the clippy repo.
changelog: new lint [`significant_drop_in_scrutinee`]
bors [Sat, 7 May 2022 22:41:39 +0000 (22:41 +0000)]
Auto merge of #96824 - matthiaskrgr:rollup-silw3ki, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #96336 (Link to correct `as_mut` in docs for `pointer::as_ref`)
- #96586 (Add aliases for std::fs::canonicalize)
- #96667 (Add regression test)
- #96671 (Remove hard links from `env::current_exe` security example)
- #96726 (Add regression and bug tests)
- #96756 (Enable compiler-docs by default for `compiler`, `codegen`, and `tools` profiles)
- #96757 (Don't constantly rebuild clippy on `x test src/tools/clippy`.)
- #96769 (Remove `adx_target_feature` feature from active features list)
- #96777 (Make the test `check-pass` not to produce a JSON file)
- #96822 (Enforce quote rule for JS source code)
Matthias Krüger [Sat, 7 May 2022 20:44:43 +0000 (22:44 +0200)]
Rollup merge of #96777 - JohnTitor:do-not-run-pass-save-analysis, r=Mark-Simulacrum
Make the test `check-pass` not to produce a JSON file
`run-pass` produces a JSON file when enabling save analysis.
The original ICE happened on `cargo check`, moreover **without** the `generic_const_exprs` feature, so `check-pass` should be enough.
Matthias Krüger [Sat, 7 May 2022 20:44:39 +0000 (22:44 +0200)]
Rollup merge of #96671 - mgeisler:current-exe-docstring, r=Mark-Simulacrum
Remove hard links from `env::current_exe` security example
The security example shows that `env::current_exe` will return the path used when the program was started. This is not really surprising considering how hard links work: after `ln foo bar`, the two files are _equivalent_. It is _not_ the case that `bar` is a “link” to `foo`, nor is `foo` a link to `bar`. They are simply two names for the same underlying data.
The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at `/proc/self/exe` (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.
I looked through the history a bit and found that the example was introduced in https://github.com/rust-lang/rust/pull/33526. That PR actually has two commits, and the first (https://github.com/rust-lang/rust/commit/8478d48dad949b3b1374569a5391089a49094eeb) explains the race condition at the root of the linked security vulnerability. The second commit proceeds to replace the explanation with the example we have today.
This commit reverts most of the second commit from https://github.com/rust-lang/rust/pull/33526.
bors [Sat, 7 May 2022 20:17:33 +0000 (20:17 +0000)]
Auto merge of #96670 - Urgau:bootstrap-check-cfg-features, r=Mark-Simulacrum
Enable cfg checking of cargo features for everything but std
This PR enable `cfg` checking of cargo features for everything but std, it also adds a `FIXME` to myself.
> Note: `std`, `alloc` and `core` imports some dependencies by #[path] (like
> backtrace, core_simd, std_float, ...), those dependencies have their own features
> but cargo isn't involved in the #[path] and so cannot pass the complete list of
> features, so for that reason we don't enable checking of features for std.
bors [Sat, 7 May 2022 17:53:59 +0000 (17:53 +0000)]
Auto merge of #96657 - cuviper:time64, r=joshtriplett
Use 64-bit time on 32-bit linux-gnu
The standard library suffered the [Year 2038 problem][Y2038] in two main places on targets with 32-bit `time_t`:
- In `std::time::SystemTime`, we stored a `timespec` that has `time_t` seconds. This is now changed to directly store 64-bit seconds and nanoseconds, and on 32-bit linux-gnu we try to use `__clock_gettime64` (glibc 2.34+) to get the larger timestamp.
- In `std::fs::Metadata`, we store a `stat64`, which has 64-bit `off_t` but still 32-bit `time_t`, and unfortunately that is baked in the API by the (deprecated) `MetadataExt::as_raw_stat()`. However, we can use `statx` for 64-bit `statx_timestamp` to store in addition to the `stat64`, as we already do to support creation time, and the rest of the `MetadataExt` methods can return those full values. Note that some filesystems may still be limited in their actual timestamp support, but that's not something Rust can change.
There remain a few places that need `timespec` for system call timeouts -- I leave that to future work.
flip1995 [Thu, 5 May 2022 14:50:11 +0000 (15:50 +0100)]
Track if a where bound comes from a impl Trait desugar
With #93803 `impl Trait` function arguments get desugared to hidden
where bounds. However, Clippy needs to know if a bound was originally a
impl Trait or an actual bound. This adds a field to the
`WhereBoundPredicate` struct to keep track of this information during
HIR lowering.
bors [Sat, 7 May 2022 13:31:04 +0000 (13:31 +0000)]
Auto merge of #96816 - GuillaumeGomez:rollup-oumn95i, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #96581 (make Size and Align debug-printing a bit more compact)
- #96636 (Fix jump to def regression)
- #96760 (diagnostics: port more diagnostics to derive + add support for `Vec` fields)
- #96788 (Improve validator around field projections and checked bin ops)
- #96805 (Change eslint rules from configuration comments to configuration file)
- #96807 (update Miri)
- #96811 (Fix a minor typo in the description of Formatter)
Guillaume Gomez [Sat, 7 May 2022 13:23:46 +0000 (15:23 +0200)]
Rollup merge of #96760 - davidtwco:diagnostic-translation-vec, r=oli-obk
diagnostics: port more diagnostics to derive + add support for `Vec` fields
- Port "unconstrained opaque type" diagnostic to using the derive.
- Allow `Vec` fields in diagnostic derive - enables support for diagnostics that have multiple primary spans, or have subdiagnostics repeated at multiple locations. `Vec<..>` fields in the diagnostic derive become loops in the generated code.
- Add `create_{err,warning}` - there wasn't a way to create a diagnostic from a struct and not emit it straight away.
- Port "explicit generic args w/ impl trait" diagnostic to using the derive.
Guillaume Gomez [Sat, 7 May 2022 13:23:44 +0000 (15:23 +0200)]
Rollup merge of #96581 - RalfJung:debug-size-align, r=oli-obk
make Size and Align debug-printing a bit more compact
In particular in `{:#?}`-mode, these take up a lot of space, so I think this is the better alternative (even though it is a bit longer in `{:?}` mode, I think it is still more readable).
We could make it even smaller by deviating further from what the actual code looks like, e.g. via something like `Size(4 bytes)`. Not sure what people would think about that?
bors [Sat, 7 May 2022 06:30:29 +0000 (06:30 +0000)]
Auto merge of #96094 - Elliot-Roberts:fix_doctests, r=compiler-errors
Begin fixing all the broken doctests in `compiler/`
Begins to fix #95994.
All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are.
There are also a few that I marked `ignore` that could maybe be made to work but seem less important.
Each `ignore` has a rough "reason" for ignoring after it parentheses, with
- `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax"
- `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy.
- `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR.
- `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup.
Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful.
I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
bors [Sat, 7 May 2022 04:15:52 +0000 (04:15 +0000)]
Auto merge of #96804 - compiler-errors:rollup-1mc6aw3, r=compiler-errors
Rollup of 8 pull requests
Successful merges:
- #96660 ([bootstrap] Give a better error when trying to run a path with no registered step)
- #96701 (update `jemallocator` example to use 2018 edition import syntax)
- #96746 (Fix an ICE on #96738)
- #96758 (bootstrap: bsd platform flags for split debuginfo)
- #96778 (Remove closures on `expect_local` to apply `#[track_caller]`)
- #96781 (Fix an incorrect link in The Unstable Book)
- #96783 (Link to correct issue in issue-95034 known-bug)
- #96801 (Add regression test for #96319)
Michael Goulet [Sat, 7 May 2022 03:49:35 +0000 (20:49 -0700)]
Rollup merge of #96781 - koic:fix_an_incorrect_link_in_the_unstable_book, r=ehuss
Fix an incorrect link in The Unstable Book
https://github.com/rust-lang/rust/blob/master/src/librustc_session/lint/builtin.rs returns page not found.
The following is the background of the move.
First https://github.com/rust-lang/rust/pull/74862 moves from src/librustc_session/lint/builtin.rs to compiler/rustc_session/src/lint/builtin.rs.
Then https://github.com/rust-lang/rust/commit/23018a5 moves from compiler/rustc_session/src/lint/builtin.rs to compiler/rustc_lint_defs/src/builtin.rs.
So, the current correct link is https://github.com/rust-lang/rust/blob/master/compiler/rustc_lint_defs/src/builtin.rs.
This PR fixes a broken link on the following page:
https://doc.rust-lang.org/beta/unstable-book/language-features/plugin.html
Michael Goulet [Sat, 7 May 2022 03:49:35 +0000 (20:49 -0700)]
Rollup merge of #96778 - JohnTitor:expect-local-track-caller-take-2, r=petrochenkov
Remove closures on `expect_local` to apply `#[track_caller]`
Pointed out in https://github.com/rust-lang/rust/pull/96747#discussion_r866576196
Didn't change `expect_non_local` as I'm not sure if it's also the case.
r? ``@petrochenkov``
Bootstrap currently provides `-Zunstable-options` for OpenBSD when using split debuginfo - this commit provides it for all BSD targets.
We should probably work out a better way of handling the stability of the split debuginfo flag - all options for the flag are unstable but one of them is the default for each platform already.
projects / rust.git / log