Matthias Krüger [Sat, 17 Dec 2022 22:44:28 +0000 (23:44 +0100)]
Rollup merge of #105814 - JakobDegen:custom-mir-terms, r=oli-obk
Support call and drop terminators in custom mir
The only caveat with this change is that cleanup blocks are not supported. I would like to add them, but it's not quite clear to me what the best way to do that is, so I'll have to think about it some more.
Matthias Krüger [Sat, 17 Dec 2022 22:44:27 +0000 (23:44 +0100)]
Rollup merge of #105789 - notriddle:notriddle/examples-margin, r=GuillaumeGomez
rustdoc: clean up margin CSS for scraped examples
* This stops applying a margin to the additional example links. Because these links are `display: inline`, it doesn't actually do anything.
* This switches from using a margin-bottom with a special exception for the examples themselves, plus an additional margin on the hide button, to instead using just margin-top on the examples, with an exception for the first one.
Matthias Krüger [Sat, 17 Dec 2022 22:44:26 +0000 (23:44 +0100)]
Rollup merge of #105458 - Ayush1325:blocking_spawn, r=Mark-Simulacrum
Allow blocking `Command::output`
### Problem
Currently, `Command::output` is internally implemented using `Command::spawn`. This is problematic because some targets (like UEFI) do not actually support multitasking and thus block while the program is executing. This coupling does not make much sense as `Command::output` is supposed to block until the execution is complete anyway and thus does not need to rely on a non-blocking `Child` or any other intermediate.
### Solution
This PR moves the implementation of `Command::output` to `std::sys`. This means targets can choose to implement only `Command::output` without having to implement `Command::spawn`.
### Additional Information
This was originally conceived when working on https://github.com/rust-lang/rust/pull/100316. Currently, the only target I know about that will benefit from this change is UEFI.
This PR can also be used to implement more efficient `Command::output` since the intermediate `Process` is not actually needed anymore, but that is outside the scope of this PR.
Since this is not a public API change, I'm not sure if an RFC is needed or not.
bors [Sat, 17 Dec 2022 14:51:10 +0000 (14:51 +0000)]
Auto merge of #105800 - lqd:dylib-thinlto, r=bjorn3
Don't copy symbols from dylibs with `-Zdylib-lto`
When `rustc_driver` started being built with `-Zdylib-lto -Clto=thin`, some libstd symbols were copied by the LTO process into the dylib. That causes duplicate local symbols that are not present otherwise.
Depending on the situation (lib loading order apparently), the duplicated symbols could cause issues: `rustc_driver` overrode the panic hook, but it didn't apply to rustc main's hook (the default from libstd). This is the cause of #105637, in some situations the panic hook installed by `rustc_driver` isn't executed, and only libstd's backtrace is shown (and a double panic). The query stack, as well as the various notes to open a GH about the ICE, don't appear.
It's not clear exactly what is needed to trigger the issue, but I have simulated a reproducer [here](https://github.com/lqd/issue-105637) with cargo involved, the incorrect panic hook is executed on my machine. It is hard to reproduce in a unit test: `cargo run` + `rustup` involves LD_LIBRARY_PATH, which is not the case for `compiletest`. cargo also adds unconditional flags that are then overridden in [`bootstrap` when building rustc with `rust.lto = thin`](https://github.com/rust-lang/rust/blob/9c07efe84f28a44f3044237696acc295aa407ee5/src/bootstrap/compile.rs#L702-L714) as done on CI).
All this to say the compilation and execution environment in `bootstrap` leading to the bug building `rustc_driver` is different from our UI tests, and I believe one of the reasons it's hard to make an exact reproducer test. Thankfully there's _still_ a difference in the behavior though: although in the unit test the correct panic hook seems to be executed compared to my repro and the current nightly, only the fix removes the double panic here.
The `7e8277aefa12f1469fb1df01418ff5846a7854a9` `try` build:
- fixes the reproducer repo linked above
- restores the ICE messages from https://github.com/rust-lang/rust/issues/105321 back to the state in its OP compared to the description in https://github.com/rust-lang/rust/issues/105637
- restores the ICE message and the query stack from https://github.com/rust-lang/rust/issues/105777 compared to nightly
While I believe this technically fixes the P-critical issue https://github.com/rust-lang/rust/issues/105637, I would not want to close it yet as we may want to backport to beta/stable (if a point release happens, it would fix the ICEs reported on 1.66.0, which is built with ThinLTO on linux). Once this PR lands, I'll also open another PR to re-enable ThinLTO on x64 darwin's dist builder.
bors [Sat, 17 Dec 2022 12:35:26 +0000 (12:35 +0000)]
Auto merge of #10096 - feniljain:fix-seek-rewind, r=xFrednet
fix: not suggest seek_to_start_instead_of_rewind when expr is used
changelog: [`seek_to_start_instead_of_rewind`]: No longer lints, if the return of `seek` is used.
[#10096](https://github.com/rust-lang/rust-clippy/pull/10096)
<!-- changelog_checked -->
bors [Sat, 17 Dec 2022 11:36:50 +0000 (11:36 +0000)]
Auto merge of #10094 - EricWu2003:increment-visitor-fix, r=xFrednet
fix logic in IncrementVisitor
There used to be a logical bug where IncrementVisitor would completely stop checking an expression/block after seeing a continue statement.
I am a little unsure of whether my fix to `IncrementVisitor` is logically sound (I hope it makes sense). Let me know what you think, and thanks in advance for the review!
fixes #10058
---
changelog: FP: [`explicit_counter_loop`]: No longer ignores counter changes after `continue` expressions
[#10094](https://github.com/rust-lang/rust-clippy/pull/10094)
<!-- changelog_checked -->
bors [Sat, 17 Dec 2022 03:11:39 +0000 (03:11 +0000)]
Auto merge of #105811 - ojeda:Dwarnings-no_fp_fmt_parse, r=Mark-Simulacrum
core: ensure `no_fp_fmt_parse` builds are warning-free
Rust recently introduced a new `unused_imports` warning in `no_fp_fmt_parse` builds, which was fixed in
https://github.com/rust-lang/rust/pull/105434.
To avoid accumulating more over time, let's keep the builds warning-free. This ensures projects compiling `core` with this custom config do not see the warnings in the future and that they can keep enabling `-Dwarnings`.
Similarly, https://github.com/rust-lang/rust/pull/98652 did it for `alloc`'s `no_global_oom_handling`.
bors [Sat, 17 Dec 2022 00:41:15 +0000 (00:41 +0000)]
Auto merge of #105804 - matthiaskrgr:rollup-iaqlbl3, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #105493 (Help rust-analyzer normalize query return types)
- #105710 (Don't bug if we're trying to cast `dyn*` to another type)
- #105711 (bail in `collect_trait_impl_trait_tys` if signatures reference errors)
- #105768 (Detect inherent associated types not having CamelCase)
- #105780 (rustdoc: Don't add "Read more" link if there is no extra content)
- #105802 (Make enum-match.rs test robust against variable name changes)
Matthias Krüger [Fri, 16 Dec 2022 23:45:50 +0000 (00:45 +0100)]
Rollup merge of #105493 - WaffleLapkin:unchoke-r-a, r=Nilstrieb
Help rust-analyzer normalize query return types
See [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/rustc.20query.20types.20are.20not.20normalized.20since.20recently/near/312686086), since https://github.com/rust-lang/rust/pull/103808, rust analyzer doesn't normalize return types of queries. This is because r-a doesn't support associated type defaults (yet).
The easiest fix is to not use associated type defaults (duh), which this PR does.
Miguel Ojeda [Fri, 16 Dec 2022 23:19:59 +0000 (00:19 +0100)]
core: ensure `no_fp_fmt_parse` builds are warning-free
Rust recently introduced a new `unused_imports` warning
in `no_fp_fmt_parse` builds, which was fixed in
https://github.com/rust-lang/rust/pull/105434.
To avoid accumulating more over time, let's keep the builds
warning-free. This ensures projects compiling `core` with
this custom config do not see the warnings in the future
and that they can keep enabling `-Dwarnings`.
Similarly, https://github.com/rust-lang/rust/pull/98652 did it
for `alloc`'s `no_global_oom_handling`.
bors [Fri, 16 Dec 2022 21:08:45 +0000 (21:08 +0000)]
Auto merge of #102318 - Amanieu:default_alloc_error_handler, r=oli-obk
Stabilize default_alloc_error_handler
Tracking issue: #66741
This turns `feature(default_alloc_error_handler)` on by default, which causes the compiler to automatically generate a default OOM handler which panics if `#[alloc_error_handler]` is not provided.
The FCP completed over 2 years ago but the stabilization was blocked due to an issue with unwinding. This was fixed by #88098 so stabilization can be unblocked.
bors [Fri, 16 Dec 2022 18:06:10 +0000 (18:06 +0000)]
Auto merge of #105018 - zertosh:path_buf_deref_mut, r=dtolnay
Implement DerefMut for PathBuf
Without this, there's no way to get a `&mut Path` from `PathBuf` without
going through `into_boxed_path`. This is relevant now that #105002 adds
`PathBuf::as_mut_os_string` and `Path::as_mut_os_str`.
Michael Howell [Fri, 16 Dec 2022 17:11:37 +0000 (10:11 -0700)]
rustdoc: clean up margin CSS for scraped examples
* This stops applying a margin to the additional example links.
Because these links are `display: inline`, it doesn't actually do anything.
* This switches from using a margin-bottom with a special exception for
the examples themselves, plus an additional margin on the hide button,
to instead using just margin-top on the examples, with an exception for
the first one.
Eric Wu [Fri, 16 Dec 2022 15:22:29 +0000 (10:22 -0500)]
fix logic in IncrementVisitor
There used to be a logical bug where IncrementVisitor would
completely stop checking an expression/block after seeing a continue
statement. This led to issue #10058 where a variable incremented
(or otherwise modified) after any continue statement would still be
considered incremented only once.
The solution is to continue scanning the expression after seeing a
`continue` statement, but increment self.depth so that the Visitor
thinks that the rest of the loop is within a conditional.
Matthias Krüger [Fri, 16 Dec 2022 13:02:18 +0000 (14:02 +0100)]
Rollup merge of #105744 - Ezrashaw:e0158-clarity, r=GuillaumeGomez
Rewrite `E0158` error-code docs for clarity
Fixes #105585.
The `E0158` error-code docs are unclear. It doesn't explain all three different variants of the error and doesn't explain *why* the error occurs. This PR cleans it up a bit and brings it properly into line with [RFC1567](https://rust-lang.github.io/rfcs/1567-long-error-codes-explanation-normalization.html).
I'm a first time Rust contributor so I've probably not got it quite right. I also haven't run the whole build process because I assume that my minor docs changes shouldn't break everything.
bors [Fri, 16 Dec 2022 09:30:56 +0000 (09:30 +0000)]
Auto merge of #105763 - Ezrashaw:rustc-book-relative-links, r=jyn514
Use relative links in the unstable and rustc book
Fixes #98227.
As it stands, potential issues could arise from mismatch of stable/ nightly in the books. This PR fixes this issue by using relative links instead of absolute ones. I have replaced every absolute link under `src/doc/rustc` and `src/doc/unstable-book/` and tested each manually.
The link at `src/doc/rustc/src/targets/index.md:7`:
`[here](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/spec/struct.Target.html).`
I need help with because my local directory structure and https://doc.rust-lang.org/ seem to be different, where is `nightly-rustc`?
bors [Thu, 15 Dec 2022 22:53:03 +0000 (22:53 +0000)]
Auto merge of #105760 - matthiaskrgr:rollup-r8beo9w, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #105481 (Start improving monomorphization items stats)
- #105674 (Point at method chains on `E0271` errors)
- #105679 (Suggest constraining type parameter with `Clone`)
- #105694 (Don't create dummy if val has escaping bounds var)
- #105727 (Tweak output for bare `dyn Trait` in arguments)
- #105739 (Migrate Jump to def links background to CSS variable)
- #105743 (`SimplifiedType` cleanups)
- #105758 (Move `TypeckResults` to separate module)
Matthias Krüger [Thu, 15 Dec 2022 21:03:01 +0000 (22:03 +0100)]
Rollup merge of #105758 - Nilstrieb:typeck-results-mod, r=compiler-errors
Move `TypeckResults` to separate module
`ty::context` is really big and the typeck results aren't directly related to `TyCtxt`, so move them to a separate module. Also contains a small drive-by macro "improvement".
Matthias Krüger [Thu, 15 Dec 2022 21:02:57 +0000 (22:02 +0100)]
Rollup merge of #105481 - lqd:mono-stats, r=wesleywiser
Start improving monomorphization items stats
As described in [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Compile-time.20case-study.3A.20AWS.20crates/near/314560832), some stats about monomorphization collection would be interesting to have, in a different form than `-Zprint-mono-items`: to have some visibility into the cost of the mono items, we'd like to know how many are instantiated and what is their estimated size.
That can be a proxy to analyze sources of slow compile times, although in the future, we'd also like to add more realistic stats from the actual backend's lowering.
This PR adds a new `-Z dump-mono-stats` flag which will output some stats in a `{crate_name}.mono-items.md` file (the flag optionally takes an output directory parameter, for easier use within a workspace than printing to stdout).
For example,
```rust
fn compute<T>(collection: Vec<T>) -> usize {
collection.len() + 19 - 0 * 9 - 18 - 1 * 1 // random code to increase the function's size
}
bors [Thu, 15 Dec 2022 19:59:48 +0000 (19:59 +0000)]
Auto merge of #105356 - JakobDegen:more-custom-mir, r=oli-obk
Custom MIR: Many more improvements
Commits are each atomic changes, best reviewed one at a time, with the exception that the last commit includes all the documentation.
### First commit
Unsafetyck was not correctly disabled before for `dialect = "built"` custom MIR. This is fixed and a regression test is added.
### Second commit
Implements `Discriminant`, `SetDiscriminant`, and `SwitchInt`.
### Third commit
Implements indexing, field, and variant projections.
### Fourth commit
Documents the previous commits and everything else.
There is some amount of weirdness here due to having to beat Rust syntax into cooperating with MIR concepts, but it hopefully should not be too much. All of it is documented.
bors [Thu, 15 Dec 2022 17:04:25 +0000 (17:04 +0000)]
Auto merge of #104616 - RalfJung:ctfe-alignment, r=oli-obk,RalfJung
always check alignment during CTFE
We originally disabled alignment checks because they got in the way -- there are some things we do with the interpreter during CTFE which does not correspond to actually running user-written code, but is purely administrative, and we didn't want alignment checks there, so we just disabled them entirely. But with `-Zextra-const-ub-checks` we anyway had to figure out how to disable those alignment checks while doing checks in regular code. So now it is easy to enable CTFE alignment checking by default. Let's see what the perf consequences of that are.
bors [Thu, 15 Dec 2022 16:12:12 +0000 (16:12 +0000)]
Auto merge of #10073 - xFrednet:changelog-1-66, r=Alexendoo
Changelog 1.66
It's really nice to see a changelog with so many suggestion fixes and improvements. Not much else to say. This should be merged with the coming release on 2022-12-15. For the reviewer, please review it and approve it if it looks good. The merge should wait until the release :)
projects / rust.git / log