Commit Graph

246092 Commits

Author SHA1 Message Date
Guillaume Gomez
0860fc14ae Add clippy into the known cfg list 2024-02-15 14:18:19 +01:00
bors
bd6b336133 Auto merge of #121125 - ehuss:fix-small-cstr, r=Mark-Simulacrum
Fix SmallCStr conversion from CStr

The conversion from CStr to SmallCStr was not including the null byte. SmallCStr requires a trailing null. This caused `as_c_str` to either panic if std is built with debug assertions, or to have some corrupt memory behavior.
2024-02-15 06:04:25 +00:00
Eric Huss
217e5e484d Fix SmallCStr conversion from CStr 2024-02-14 18:40:53 -08:00
bors
ee9c7c940c Auto merge of #120847 - oli-obk:track_errors9, r=compiler-errors
Continue compilation after check_mod_type_wf errors

The ICEs fixed here were probably reachable through const eval gymnastics before, but now they are easily reachable without that, too.

The new errors are often bugfixes, where useful errors were missing, because they were reported after the early abort. In other cases sometimes they are just duplication of already emitted errors, which won't be user-visible due to deduplication.

fixes https://github.com/rust-lang/rust/issues/120860
2024-02-14 18:32:19 +00:00
bors
502ce8287b Auto merge of #121086 - GuillaumeGomez:rollup-y82fs9y, r=GuillaumeGomez
Rollup of 6 pull requests

Successful merges:

 - #120893 (Move some tests)
 - #120966 (Remove importing suggestions when there is a shadowed typo candidate)
 - #121035 (Format `async` trait bounds in rustfmt)
 - #121075 (Fix false positive with if let and ranges)
 - #121083 (Extend documentation for `Ty::to_opt_closure_kind` method)
 - #121084 (Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-14 15:45:34 +00:00
Guillaume Gomez
2062325145
Rollup merge of #121084 - oli-obk:create_def_forever_red2, r=WaffleLapkin
Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`

oversight from https://github.com/rust-lang/rust/pull/119136

Not actually an issue, because all uses of `tcx.create_def` were in the resolver, which is `eval_always`, but still good to harden against future uses of `create_def`

cc `@petrochenkov` `@WaffleLapkin`
2024-02-14 15:41:30 +01:00
Guillaume Gomez
c2ae07d20d
Rollup merge of #121083 - GuillaumeGomez:doc-to_opt_closure_kind, r=compiler-errors
Extend documentation for `Ty::to_opt_closure_kind` method

This API was... surprising to use. With a little extra documentation, the weirdness can be reduced quite a lot. :)

r? `@compiler-errors`
2024-02-14 15:41:29 +01:00
Guillaume Gomez
18c935d000
Rollup merge of #121075 - chenyukang:yukang-fix-121070-lint-range, r=oli-obk
Fix false positive with if let and ranges

Fixes #121070
2024-02-14 15:41:28 +01:00
Guillaume Gomez
dd4851b338
Rollup merge of #121035 - compiler-errors:rustfmt-asyncness, r=calebcartwright
Format `async` trait bounds in rustfmt

r? `@ytmimi` or `@calebcartwright`

This PR opts to do formatting in the rust-lang/rust tree because otherwise we'd have to wait until a full sync, and rustfmt is currently totally removing the `async` keyword.

cc https://github.com/rust-lang/rustfmt/issues/6070
2024-02-14 15:41:27 +01:00
Guillaume Gomez
8e690fdd6a
Rollup merge of #120966 - chenyukang:yukang-fix-120599-resolve, r=pnkfelix
Remove importing suggestions when there is a shadowed typo candidate

Fixes #120559
2024-02-14 15:41:27 +01:00
Guillaume Gomez
b36e094802
Rollup merge of #120893 - c410-f3r:testsssssss, r=petrochenkov
Move some tests

r? `@petrochenkov`
2024-02-14 15:41:26 +01:00
Guillaume Gomez
9ef9f737ca Extend documentation for Ty::to_opt_closure_kind method 2024-02-14 15:24:44 +01:00
Oli Scherer
2e900edde1 Make sure tcx.create_def also depends on the forever red node, instead of just tcx.at(span).create_def 2024-02-14 14:08:19 +00:00
bors
340bb19fea Auto merge of #121078 - oli-obk:rollup-p11zsav, r=oli-obk
Rollup of 13 pull requests

Successful merges:

 - #116387 (Additional doc links and explanation of `Wake`.)
 - #118738 (Netbsd10 update)
 - #118890 (Clarify the lifetimes of allocations returned by the `Allocator` trait)
 - #120498 (Uplift `TypeVisitableExt` into `rustc_type_ir`)
 - #120530 (Be less confident when `dyn` suggestion is not checked for object safety)
 - #120915 (Fix suggestion span for `?Sized` when param type has default)
 - #121015 (Optimize `delayed_bug` handling.)
 - #121024 (implement `Default` for `AsciiChar`)
 - #121039 (Correctly compute adjustment casts in GVN)
 - #121045 (Fix two UI tests with incorrect directive / invalid revision)
 - #121049 (Do not point at `#[allow(_)]` as the reason for compat lint triggering)
 - #121071 (Use fewer delayed bugs.)
 - #121073 (Fix typos in `OneLock` doc)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-14 12:04:03 +00:00
Oli Scherer
25806f8d80 Use the correct char type on all platforms 2024-02-14 11:12:19 +00:00
Oli Scherer
5f6390f947 Continue compilation after check_mod_type_wf errors 2024-02-14 11:00:30 +00:00
Oli Scherer
96635da982
Rollup merge of #121073 - IgorLaborieWefox:patch-1, r=workingjubilee
Fix typos in `OneLock` doc
2024-02-14 11:53:43 +01:00
Oli Scherer
638f5259fe
Rollup merge of #121071 - nnethercote:fewer-delayed-bugs, r=oli-obk
Use fewer delayed bugs.

For some cases where it's clear that an error has already occurred, e.g.:
- there's a comment stating exactly that, or
- things like HIR lowering, where we are lowering an error kind

The commit also tweaks some comments around delayed bug sites.

r? `@oli-obk`
2024-02-14 11:53:42 +01:00
Oli Scherer
9e31121985
Rollup merge of #121049 - estebank:issue-121009, r=fmease
Do not point at `#[allow(_)]` as the reason for compat lint triggering

Fix #121009.
2024-02-14 11:53:42 +01:00
Oli Scherer
f77870e170
Rollup merge of #121045 - jieyouxu:fix-ui-tests, r=oli-obk
Fix two UI tests with incorrect directive / invalid revision

- `tests/ui/borrowck/copy-suggestion-region-vid.rs` had a `ui_test`-style directive on compiletest: `//`@run-rustfix`.`
- `tests/ui/asm/inline-syntax.rs` has directives for a undeclared revision `[x86_64_allowed]` which seems to have the same directives as declared revision `[x86_64]`.
2024-02-14 11:53:41 +01:00
Oli Scherer
93bc34073e
Rollup merge of #121039 - cjgillot:gvn-adjust, r=compiler-errors
Correctly compute adjustment casts in GVN

Fixes https://github.com/rust-lang/rust/issues/120925

r? `@oli-obk`
2024-02-14 11:53:41 +01:00
Oli Scherer
c1a80211f5
Rollup merge of #121024 - joseluis:feat-asciichar-default, r=scottmcm
implement `Default` for `AsciiChar`

This implements `Default` for `AsciiChar` in order to match `char`'s implementation.

From all the different possible ways to do this I think the clearest one is to have both `char` and `AsciiChar` impls together.

I've also updated the doc-comment of the default variant since rustdoc doesn't seem to indicate it otherwise. Probably the text could be improved, though. I couldn't find any similar examples in the codebase and suggestions are welcomed.

r? `@scottmcm`
2024-02-14 11:53:40 +01:00
Oli Scherer
bad2cb08de
Rollup merge of #121015 - nnethercote:opt-delayed-bug, r=oli-obk
Optimize `delayed_bug` handling.

Once we have emitted at least one error, delayed bugs won't be used. So we can (a) we can (a) discard any existing delayed bugs, and (b) stop recording any new delayed bugs.

This eliminates a longstanding `FIXME` comment. There should be no soundness issues because it's not possible to un-emit an error.

r? `@oli-obk`
2024-02-14 11:53:40 +01:00
Oli Scherer
f3e66edd63
Rollup merge of #120915 - OdenShirataki:master, r=fmease
Fix suggestion span for `?Sized` when param type has default

Fixes #120878

Diagnostic suggests adding `: ?Sized` in an incorrect place if a type parameter default is present

r? `@fmease`
2024-02-14 11:53:39 +01:00
Oli Scherer
c4371a79de
Rollup merge of #120530 - trevyn:issue-116434, r=compiler-errors
Be less confident when `dyn` suggestion is not checked for object safety

#120275 no longer checks bare traits for object safety when making a `dyn` suggestion on Rust < 2021. In this case, qualify the suggestion with a note that the trait must be object safe, to prevent user confusion as seen in #116434

r? ```@fmease```
2024-02-14 11:53:39 +01:00
Oli Scherer
cc54612ac3
Rollup merge of #120498 - compiler-errors:type-flags, r=lcnr
Uplift `TypeVisitableExt` into `rustc_type_ir`

This uplifts `TypeVisitableExt` into `rustc_type_ir` so it can be used in an interner-agnostic way. It also moves some `TypeSuperVisitable` bounds onto `Interner` since we don't expect to support libraries that have types which aren't foldable by default.

This restores a couple of asserts in the canonicalizer code we uplifted, and also makes it so that we can use type-flags-based helpers in the solver code, which I'm interested in uplifting.

r? lcnr
2024-02-14 11:53:38 +01:00
Oli Scherer
407de0ee33
Rollup merge of #118890 - Amanieu:allocator-lifetime, r=Mark-Simulacrum
Clarify the lifetimes of allocations returned by the `Allocator` trait

The previous definition (accidentally) disallowed the implementation of stack-based allocators whose memory would become invalid once the lifetime of the allocator type ended.

This also ensures the validity of the following blanket implementation:
```rust
impl<A: Allocator> Allocator for &'_ A {}
```
2024-02-14 11:53:38 +01:00
Oli Scherer
1c7a9996f0
Rollup merge of #118738 - devnexen:netbsd10_update, r=cuviper
Netbsd10 update
2024-02-14 11:53:38 +01:00
Oli Scherer
5d114f3c99
Rollup merge of #116387 - kpreid:wake-doc, r=cuviper
Additional doc links and explanation of `Wake`.

This is intended to clarify:

* That `Wake` exists and can be used instead of `RawWaker`.
* How to construct a `Waker` when you are looking at `Wake` (which was previously only documented in the example).
2024-02-14 11:53:37 +01:00
bors
81b757c670 Auto merge of #100603 - tmandry:zst-guards, r=dtolnay
Optimize away poison guards when std is built with panic=abort

> **Note**: To take advantage of this PR, you will have to use `-Zbuild-std` or build your own toolchain. rustup toolchains always link to a libstd that was compiled with `panic=unwind`, since it's compatible with `panic=abort` code.

When std is compiled with `panic=abort` we can remove a lot of the poison machinery from the locks. This changes the `Flag` and `Guard` types to be ZSTs. It also adds an uninhabited member to `PoisonError` so the compiler knows it can optimize away the `Result::Err` paths, and make `LockResult<T>` layout-equivalent to `T`.

### Is this a breaking change?

`PoisonError::new` now panics if invoked from a libstd built with `panic="abort"` (or any non-`unwind` strategy). It is unclear to me whether to consider this a breaking change.

In order to encounter this behavior, **both of the following must be true**:

#### Using a libstd with `panic="abort"`

This is pretty uncommon. We don't build libstd with that in rustup, except in (Tier 2-3) platforms that do not support unwinding, **most notably wasm**.

Most people who do this are using cargo's `-Z build-std` feature, which is unstable.

`panic="abort"` is not a supported option in Rust's build system. It is possible to configure it using `CARGO_TARGET_xxx_RUSTFLAGS`, but I believe this only works on **non-host** platforms.

#### Creating `PoisonError` manually

This is also unlikely. The only common use case I can think of is in tests, and you can't run tests with `panic="abort"` without the unstable `-Z panic_abort_tests` flag.

It's possible that someone is implementing their own locks using std's `PoisonError` **and** defining "thread failure" to mean something other than "panic". If this is the case then we would break their code if it was used with a `panic="abort"` libstd. The locking crates I know of don't replicate std's poison API, but I haven't done much research into this yet.

I've touched on a fair number of considerations here. Which ones do people consider relevant?
2024-02-14 10:07:01 +00:00
Nicholas Nethercote
05849e8c2f Use fewer delayed bugs.
For some cases where it's clear that an error has already occurred,
e.g.:
- there's a comment stating exactly that, or
- things like HIR lowering, where we are lowering an error kind

The commit also tweaks some comments around delayed bug sites.
2024-02-14 20:30:37 +11:00
许杰友 Jieyou Xu (Joe)
ee88f3435a
Fix two UI tests with incorrect directive / invalid revision 2024-02-14 09:13:53 +00:00
bors
bb89df6903 Auto merge of #121018 - oli-obk:impl_unsafety, r=TaKO8Ki
Fully stop using the HIR in trait impl checks

At least I hope I found all happy path usages. I'll need to check if I can figure out a way to make queries declare that they don't access the HIR except in error paths
2024-02-14 07:27:11 +00:00
yukang
2fe73cea5e Fix false positive with if let and ranges 2024-02-14 15:15:22 +08:00
Igor
b06f89187b
Fix typos in OneLock doc 2024-02-14 07:41:28 +01:00
yukang
2a229c96e8 remove importing suggestions when there is a shadowed typo canddiate 2024-02-14 14:08:51 +08:00
bors
cc1c0990ab Auto merge of #120454 - clubby789:cargo-update, r=Nilstrieb
`cargo update`

Run `cargo update`, with some pinning and fixes necessitated by that. This *should* unblock #112865

There's a couple of places where I only pinned a dependency in one location - this seems like a bit of a hack, but better than duplicating the FIXME across all `Cargo.toml` where a dependency is introduced.

cc `@Nilstrieb`
2024-02-14 05:27:31 +00:00
bors
7508c3e4c1 Auto merge of #121055 - matthiaskrgr:rollup-bzn5sda, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #118882 (Check normalized call signature for WF in mir typeck)
 - #120999 (rustdoc: replace `clean::InstantiationParam` with `clean::GenericArg`)
 - #121002 (remove unnecessary calls to `commit_if_ok`)
 - #121005 (Remove jsha from the rustdoc review rotation)
 - #121014 (Remove `force_print_diagnostic`)
 - #121043 (add lcnr to the compiler-team assignment group)
 - #121046 (Fix incorrect use of `compile_fail`)
 - #121047 (Do not assemble candidates for default impls)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-02-14 03:21:31 +00:00
bors
37b65339c8 Auto merge of #120942 - compiler-errors:deep-assoc-hang, r=lcnr
Ignore own item bounds in parent alias types in `for_each_item_bound`

Fixes #120912

I want to get a vibe check on this approach, which is very obviously a hack, but I believe something that is forwards-compatible with a more thorough solution and "good enough for now".

The problem here is that for a really deep rigid associated type, we are now repeatedly considering unrelated item bounds from the parent alias types, meaning we're doing a *lot* of extra work in the MIR inliner for deeply substituted rigid projections.

This feels intimately related to #107614. In that PR, we split *supertrait* bounds (bound which share the same `Self` type as the predicate which is being elaborated) and *implied* bounds (anything that is implied by elaborating the predicate).

The problem here is related to the fact that we don't maintain the split between these two for `item_bounds`. If we did, then when recursing into a parent alias type, we'd want to consider only the bounds that are given by [`PredicateFilter::All`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly) **except** those given by [`PredicateFilter::SelfOnly`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly).
2024-02-14 01:23:46 +00:00
Matthias Krüger
ab1fa19d08
Rollup merge of #121047 - compiler-errors:default-impls, r=lcnr
Do not assemble candidates for default impls

There is no reason (as far as I can tell?) that we should assemble an impl candidate for a default impl. This candidate itself does not prove that the impl holds, and any time that it *does* hold, there will be a more specializing non-default impl that also is assembled.

This is because `default impl<T> Foo for T {}` actually expands to `impl<T> Foo for T where T: Foo {}`. The only way to satisfy that where clause (without coinduction) is via *another* implementation that does hold -- precisely an impl that specializes it.

This should fix the specialization related regressions for #116494. That should lead to one root crate regression that doesn't have to do with specialization, which I think we can regress.

r? lcnr cc ``@rust-lang/types``

cc #31844
2024-02-13 22:51:57 +01:00
Matthias Krüger
e499e99a42
Rollup merge of #121046 - camelid:rm-incorrect-compile_fail, r=Nilstrieb
Fix incorrect use of `compile_fail`

`compile_fail` should only be used when the code is meant to show what *not* to do. In other words, there should be a fundamental flaw in the code. However, in this case, the example is just incomplete, so we should use `ignore` to avoid confusing readers.
2024-02-13 22:51:56 +01:00
Matthias Krüger
8775df3b11
Rollup merge of #121043 - lcnr:lcnr-compiler-assign, r=fmease
add lcnr to the compiler-team assignment group
2024-02-13 22:51:56 +01:00
Matthias Krüger
8c0d54fad6
Rollup merge of #121014 - nnethercote:rm-force_print_diagnostic, r=oli-obk
Remove `force_print_diagnostic`

More diagnostic cleanups, best reviewed one at a time.

r? `@oli-obk`
2024-02-13 22:51:55 +01:00
Matthias Krüger
8f9779f04a
Rollup merge of #121005 - fmease:update-rustdoc-review-rotation, r=jsha
Remove jsha from the rustdoc review rotation

As discussed
r? ``@jsha``
2024-02-13 22:51:55 +01:00
Matthias Krüger
147fd3f236
Rollup merge of #121002 - lcnr:cleanup-commit_if_ok, r=oli-obk
remove unnecessary calls to `commit_if_ok`

we propagate the error outwards, so anything which wants to discard the error should do so itself.

r? types
2024-02-13 22:51:55 +01:00
Matthias Krüger
2e98b27d94
Rollup merge of #120999 - fmease:rustdoc-rm-instantiation-param, r=notriddle
rustdoc: replace `clean::InstantiationParam` with `clean::GenericArg`

Probably better known as `SubstParam` (until #120958 which should've probably renamed it to `InstantiatedParam` but anyways).

It doesn't make any sense to me why it should exist as a separate type. `GenericArg` is exactly what we want here anyways from a semantic perspective. Both have the same size btw.

I also took the liberty of doing some drive-by cleanups.
2024-02-13 22:51:54 +01:00
Matthias Krüger
db9591cfb6
Rollup merge of #118882 - compiler-errors:normalized-sig-wf, r=lcnr
Check normalized call signature for WF in mir typeck

Unfortunately we don't check that the built-in implementations for `Fn*` traits are actually well-formed in the same way that we do for user-provided impls.

Essentially, when checking a call terminator, we end up with a signature that references an unnormalized `<[closure] as FnOnce<...>>::Output` in its output. That output type, due to the built-in impl, doesn't follow the expected rule that `WF(ty)` implies `WF(normalized(ty))`. We fix this by also checking the normalized signature here.

**See** boxy's detailed and useful explanation comment which explains this in more detail: https://github.com/rust-lang/rust/issues/114936#issuecomment-1710388741

Fixes #114936
Fixes #118876

r? types
cc ``@BoxyUwU`` ``@lcnr``
2024-02-13 22:51:53 +01:00
clubby789
9b73db3f1c cargo update 2024-02-13 21:24:16 +00:00
Nicholas Nethercote
71f2e3a095 Optimize delayed_bug handling.
Once we have emitted at least one error, delayed bugs won't be used. So
we can (a) we can (a) discard any existing delayed bugs, and (b) stop
recording any new delayed bugs.

This eliminates a longstanding `FIXME` comment. There should be no
soundness issues because it's not possible to un-emit an error.
2024-02-14 08:13:06 +11:00
clubby789
002181f3ce Pin cc version 2024-02-13 21:13:06 +00:00