Commit Graph

14120 Commits

Author SHA1 Message Date
bors
4d296eabe4 Auto merge of #132384 - matthiaskrgr:rollup-0ze5wc4, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #132347 (Remove `ValueAnalysis` and `ValueAnalysisWrapper`.)
 - #132365 (pass `RUSTC_HOST_FLAGS` at once without the for loop)
 - #132366 (Do not enforce `~const` constness effects in typeck if `rustc_do_not_const_check`)
 - #132376 (Annotate `input` reference tests)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-31 06:22:57 +00:00
许杰友 Jieyou Xu (Joe)
cfb4c05d77 Add a mir-opt GVN test for #128299
Co-authored-by: DianQK <dianqk@dianqk.net>
2024-10-31 13:48:35 +08:00
许杰友 Jieyou Xu (Joe)
10b8ba4ecb Mark simplify_aggregate_to_copy mir-opt as unsound
Co-authored-by: DianQK <dianqk@dianqk.net>
2024-10-31 13:48:06 +08:00
许杰友 Jieyou Xu (Joe)
4d8bda335e Add a regression test for #132353
To catch at least one pattern that was miscompiled. The test is a
minimization of the MCVE reported in
<https://github.com/rust-lang/rust/issues/132353>.
2024-10-31 13:12:22 +08:00
Matthias Krüger
49a76c14c4
Rollup merge of #132376 - ehuss:reference-input, r=traviscross
Annotate `input` reference tests

This adds test annotations for rules in the [input chapter](https://doc.rust-lang.org/nightly/reference/input-format.html) of the reference.
2024-10-31 06:11:58 +01:00
Matthias Krüger
39086e4290
Rollup merge of #132366 - compiler-errors:do-not-const-check, r=fee1-dead
Do not enforce `~const` constness effects in typeck if `rustc_do_not_const_check`

Fixes a slight inconsistency between HIR and MIR enforcement of `~const` :D

r? `@rust-lang/project-const-traits`
2024-10-31 06:11:58 +01:00
bors
c8b83785dc Auto merge of #131186 - compiler-errors:precise-capturing-borrowck, r=estebank
Try to point out when edition 2024 lifetime capture rules cause borrowck issues

Lifetime capture rules in 2024 are modified to capture more lifetimes, which sometimes lead to some non-local borrowck errors. This PR attempts to link these back together with a useful note pointing out the capture rule changes.

This is not a blocking concern, but I'd appreciate feedback (though, again, I'd like to stress that I don't want to block this PR on this): I'm worried about this note drowning in the sea of other diagnostics that borrowck emits. I was tempted to change the level of the note to `.span_warn` just so it would show up in a different color. Thoughts?

Fixes #130545

Opening as a draft first since it's stacked on #131183.
r? `@ghost`
2024-10-31 03:36:06 +00:00
Michael Goulet
c1457798db Try to point out when edition 2024 lifetime capture rules cause borrowck issues 2024-10-31 01:35:14 +00:00
bors
75eff9a574 Auto merge of #132377 - matthiaskrgr:rollup-3p1c6hs, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 - #132368 (Remove `do_not_const_check` from `Iterator` methods)
 - #132373 (Make sure `type_param_predicates` resolves correctly for RPITIT)
 - #132374 (Remove dead code stemming from the old effects desugaring)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-31 00:46:22 +00:00
Matthias Krüger
efd5645e43
Rollup merge of #132373 - compiler-errors:rpitit-bound, r=fmease
Make sure `type_param_predicates` resolves correctly for RPITIT

After #132194, we end up lowering the item bounds for an RPITIT in an `ItemCtxt` whose def id is the *synthetic GAT*, not the opaque type from the HIR.

This means that when we're resolving a shorthand projection like `T::Assoc`, we call the `type_param_predicates` function with the `item_def_id` of the *GAT* and not the opaque. That function operates on the HIR, and is not designed to work with the `Node::Synthetic` that gets fed for items synthesized by the compiler...

This PR reuses the trick we use elsewhere in lowering, where we intercept whether an item comes from RPITIT lowering, and forwards the query off to the correct item.

Fixes #132372
2024-10-31 01:14:03 +01:00
Michael Goulet
06a49b609f Validate associated type bounds on ? 2024-10-31 00:09:52 +00:00
Eric Huss
37c3884152 Annotate input reference tests 2024-10-30 16:47:47 -07:00
Michael Goulet
e356279bdf Actually do validation for poly trait refs with ? modifier 2024-10-30 23:42:50 +00:00
Michael Goulet
d53ca63453 Make sure type_param_predicates resolves correctly for RPITIT 2024-10-30 22:30:28 +00:00
Zalathar
ce3e14a448 Remove support for -Zprofile (gcov-style coverage instrumentation) 2024-10-31 09:09:25 +11:00
Jubilee
847b6fe6b0
Rollup merge of #132246 - workingjubilee:campaign-on-irform, r=compiler-errors
Rename `rustc_abi::Abi` to `BackendRepr`

Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.

Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
2024-10-30 14:01:37 -07:00
Jubilee
62ba25de39
Rollup merge of #132210 - notriddle:notriddle/doctest-span-hack, r=GuillaumeGomez
rustdoc: make doctest span tweak a 2024 edition change

Fixes #132203

This is a compatibility hack, because I think the new behavior is better. When an A `include_str!` B, and B `include_str!` C, the path to C should be resolved relative to B, not A. That's how `include!` itself works, so that's how `include_str!` with should work.
2024-10-30 14:01:37 -07:00
Jubilee
6b60f03f15
Rollup merge of #129383 - cjgillot:opaque-noremap, r=compiler-errors,petrochenkov
Remap impl-trait lifetimes on HIR instead of AST lowering

Current AST->HIR lowering goes out of its way to remap lifetimes for opaque types. This is complicated and leaks into upstream and downstream code.

This PR stops trying to be clever during lowering, and prefers to do this remapping during the HIR->ty lowering. The remapping computation easily fits into the bound var resolution code. Its result can be used in by `generics_of` and `hir_ty_lowering::new_opaque` to add the proper parameters and arguments.

See an example on the doc for query `opaque_captured_lifetimes`.

Based on https://github.com/rust-lang/rust/pull/129244/

Fixes https://github.com/rust-lang/rust/issues/125249
Fixes https://github.com/rust-lang/rust/issues/126850

cc `@compiler-errors` `@spastorino`
r? `@petrochenkov`
2024-10-30 14:01:36 -07:00
Michael Howell
ac7de1a0d9 Ignore Windows due to its differing path syntax 2024-10-30 12:39:05 -07:00
Michael Goulet
ec033e5bf1 Do not enforce ~const constness effects in typeck if rustc_do_mot_const_check 2024-10-30 17:41:09 +00:00
Camille GILLOT
2d74d8f333 Actually capture all in-scope lifetimes. 2024-10-30 16:22:23 +00:00
Camille GILLOT
8f6e0a6a4b Promote test. 2024-10-30 16:22:14 +00:00
Camille GILLOT
d693e19268 Promote crashes tests to ui. 2024-10-30 16:19:53 +00:00
Camille GILLOT
b6e1214ac0 Remap impl-trait lifetimes on HIR instead of AST lowering. 2024-10-30 16:18:50 +00:00
DianQK
416017d2de
Add a regression test for #131031
The failure output is:
```
SplitVectorOperand Op #1: t51: i32 = llvm.wasm.alltrue TargetConstant:i32<12408>, t50

rustc-LLVM ERROR: Do not know how to split this operator's operand!
```
2024-10-30 22:34:45 +08:00
许杰友 Jieyou Xu (Joe)
a864e30269
Rollup merge of #131096 - GuillaumeGomez:rm-no_unused, r=notriddle
rustdoc: Remove usage of `allow(unused)` attribute on `no_run` merged doctests

Fixes [#130681](https://github.com/rust-lang/rust/issues/130681).

It fixes the behaviour difference with the current doctests.

r? ``@notriddle``
2024-10-30 22:22:04 +08:00
许杰友 Jieyou Xu (Joe)
8d9686efc2
Rollup merge of #130098 - adetaylor:arbitrary-self-types-block-generics, r=wesleywiser
Reject generic self types.

The RFC for arbitrary self types v2 declares that we should reject "generic" self types. This commit does so.

The definition of "generic" was unclear in the RFC, but has been explored in
https://github.com/rust-lang/rust/issues/129147
and the conclusion is that "generic" means any `self` type which is a type parameter defined on the method itself, or references to such a type.

This approach was chosen because other definitions of "generic" don't work. Specifically,
* we can't filter out generic type _arguments_, because that would filter out Rc<Self> and all the other types of smart pointer we want to support;
* we can't filter out all type params, because Self itself is a type param, and because existing Rust code depends on other type params declared on the type (as opposed to the method).

This PR decides to make a new error code for this case, instead of reusing the existing E0307 error. This makes the code a bit more complex, but it seems we have an opportunity to provide specific diagnostics for this case so we should do so.

This PR filters out generic self types whether or not the 'arbitrary self types' feature is enabled. However, it's believed that it can't have any effect on code which uses stable Rust, since there are no stable traits which can be used to indicate a valid generic receiver type, and thus it would have been impossible to write code which could trigger this new error case. It is however possible that this could break existing code which uses either of the unstable `arbitrary_self_types` or `receiver_trait` features. This breakage is intentional; as we move arbitrary self types towards stabilization we don't want to continue to support generic such types.

This PR adds lots of extra tests to arbitrary-self-from-method-substs. Most of these are ways to trigger a "type mismatch" error which 9b82580c73/compiler/rustc_hir_typeck/src/method/confirm.rs (L519) hopes can be minimized by filtering out generics in this way. We remove a FIXME from confirm.rs suggesting that we make this change. It's still possible to cause type mismatch errors, and a subsequent PR may be able to improve diagnostics in this area, but it's harder to cause these errors without contrived uses of the turbofish.

This is a part of the arbitrary self types v2 project, https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? `@wesleywiser`
2024-10-30 22:22:02 +08:00
Adrian Taylor
6d8d79595e Reject generic self types.
The RFC for arbitrary self types v2 declares that we should reject
"generic" self types. This commit does so.

The definition of "generic" was unclear in the RFC, but has been
explored in
https://github.com/rust-lang/rust/issues/129147
and the conclusion is that "generic" means any `self` type which
is a type parameter defined on the method itself, or references
to such a type.

This approach was chosen because other definitions of "generic"
don't work. Specifically,
* we can't filter out generic type _arguments_, because that would
  filter out Rc<Self> and all the other types of smart pointer
  we want to support;
* we can't filter out all type params, because Self itself is a
  type param, and because existing Rust code depends on other
  type params declared on the type (as opposed to the method).

This PR decides to make a new error code for this case, instead of
reusing the existing E0307 error. This makes the code a
bit more complex, but it seems we have an opportunity to provide
specific diagnostics for this case so we should do so.

This PR filters out generic self types whether or not the
'arbitrary self types' feature is enabled. However, it's believed
that it can't have any effect on code which uses stable Rust, since
there are no stable traits which can be used to indicate a valid
generic receiver type, and thus it would have been impossible to
write code which could trigger this new error case.
It is however possible that this could break existing code which
uses either of the unstable `arbitrary_self_types` or
`receiver_trait` features. This breakage is intentional; as
we move arbitrary self types towards stabilization we don't want
to continue to support generic such types.

This PR adds lots of extra tests to arbitrary-self-from-method-substs.
Most of these are ways to trigger a "type mismatch" error which
9b82580c73/compiler/rustc_hir_typeck/src/method/confirm.rs (L519)
hopes can be minimized by filtering out generics in this way.
We remove a FIXME from confirm.rs suggesting that we make this change.
It's still possible to cause type mismatch errors, and a subsequent
PR may be able to improve diagnostics in this area, but it's harder
to cause these errors without contrived uses of the turbofish.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? @wesleywiser
2024-10-30 10:48:08 +00:00
bors
298c7462c3 Auto merge of #130860 - tmandry:fix-directives, r=jieyouxu
Fix directives for lint-non-snake-case-crate

This test fails on targets without unwinding or with `--target-rustcflags=-Cpanic=abort` because the proc macro was compiled as the target, not the host. Some targets were explicitly disabled to pass CI, but these directives are more general.

* `needs-dynamic-linking` is self explanatory
* `force-host` for proc macros
* `no-prefer-dynamic` is apparently also used for proc macros

Note that `needs-unwind` can also be useful for situations other than proc macros where unwinding is necessary.

r? `@jieyouxu`

try-job: test-various
2024-10-30 10:28:56 +00:00
Jubilee Young
083a362dd1 tests: Bless rustc_abi::Abi::Aggregate => ::Memory 2024-10-30 01:41:31 -07:00
Jubilee Young
0b9d1eb889 tests: cross-compile multi-platform ZST ABI tests
This allows them to be blessed, regardless of platform.
2024-10-30 01:41:27 -07:00
Matthias Krüger
2480e3bbc5
Rollup merge of #132332 - nnethercote:use-token_descr-more, r=estebank
Use `token_descr` more in error messages

This is the first two commits from #124141, put into their own PR to get things rolling. Commit messages have the details.

r? ``@estebank``
cc ``@petrochenkov``
2024-10-30 06:40:36 +01:00
Matthias Krüger
87d348b333
Rollup merge of #129394 - Jarcho:irrefutable_let_patterns, r=Nadrieril
Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains

fixes #128661

Is there any preference where the test goes? There looks to be several places it could fit.
2024-10-30 06:40:34 +01:00
Tyler Mandry
d942113fdb Fix directives for lint-non-snake-case-crate
This test fails on targets without unwinding because the proc macro was
compiled as the target, not the host. Some targets were explicitly
disabled to pass CI, but these directives are more general.

Fixes Fuchsia tests.
2024-10-29 16:40:06 -07:00
Jason Newcomb
4a2e08af22 Don't lint irrefutable_let_patterns on leading patterns if else if let-chains. 2024-10-29 14:43:50 -04:00
Matthias Krüger
f9fdd63cf4
Rollup merge of #132157 - estebank:long-types-3, r=jieyouxu
Remove detail from label/note that is already available in other note

Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
vs the prior

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```

*Ignore first three commits from https://github.com/rust-lang/rust/pull/132086.*
2024-10-29 18:38:58 +01:00
Matthias Krüger
5dc36391fe
Rollup merge of #132151 - compiler-errors:coroutine-resume-outlives, r=spastorino
Ensure that resume arg outlives region bound for coroutines

When proving that `{Coroutine}: 'region`, we must also prove that the coroutine's resume ty outlives that region as well. See the inline comment.

Fixes #132104
2024-10-29 18:38:57 +01:00
Matthias Krüger
5d6c49938e
Rollup merge of #131984 - dingxiangfei2009:stabilize-if-let-rescope, r=traviscross,lcnr
Stabilize if_let_rescope

Close #131154
Tracked by #124085
2024-10-29 18:38:57 +01:00
Esteban Küber
5b54286640 Remove detail from label/note that is already available in other note
Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
vs the prior

```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
  --> $DIR/wf-static-type.rs:10:13
   |
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
   |             ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
   |
   = note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
  --> $DIR/wf-static-type.rs:7:17
   |
LL | struct IsCopy<T:Copy> { t: T }
   |                 ^^^^ required by this bound in `IsCopy`
```
2024-10-29 16:26:57 +00:00
Jubilee
096363626a
Rollup merge of #132312 - jieyouxu:delete-crashes-23707, r=matthiaskrgr
Delete `tests/crashes/23707.rs` because it's flaky

It's conditioned on `only-x86_64` because it doesn't reliably fail on other platforms, it's optimization dependent and failed to ICE post-PGO in
<https://github.com/rust-lang/rust/pull/132300#issuecomment-2443279042>. Remove this test for now without prejudice against relanding the test in a more reliable form.

I removed the `S-bug-has-test` label from #23707.

r? compiler
2024-10-29 03:11:45 -07:00
Jubilee
423d4f0c2f
Rollup merge of #132266 - krasimirgg:llvm-20-testfix, r=hanna-kruppe,beetrees,workingjubilee
riscv-soft-abi-with-float-features.rs: adapt for LLVM 20

Adapts a test for LLVM 20. No functional changes intended.
2024-10-29 03:11:43 -07:00
Jubilee
b8f08fe023
Rollup merge of #132194 - compiler-errors:rpitit-super-wc, r=spastorino
Collect item bounds for RPITITs from trait where clauses just like associated types

We collect item bounds from trait where clauses for *associated types*, i.e. this:

```rust
trait Foo
where
    Self::Assoc: Send
{
    type Assoc;
}
```

Becomes this:

```rust
trait Foo {
    type Assoc: Send;
}
```

Today, with RPITITs/AFIT and return-type notation, we don't do that, i.e.:

```rust
trait Foo where Self::method(..): Send {
    fn method() -> impl Sized;
}

fn is_send(_: impl Send) {}
fn test<T: Foo>() {
    is_send(T::method());
}
```

...which fails on nightly today.

 Turns out it's super easy to fix this, and we just need to use the `associated_type_bounds` lowering function in `explicit_item_bounds_with_filter`, which has that logic baked in.
2024-10-29 03:11:41 -07:00
Jubilee
e97286e738
Rollup merge of #132119 - compiler-errors:effects-old-solver, r=lcnr
Hack out effects support for old solver

Opening this for vibes 

Turns out that a basic, somewhat incomplete implementation of host effects is achievable in the old trait solver pretty easily. This should be sufficient for us to use in the standard library itself.

Regarding incompleteness, maybe we should always treat host predicates as ambiguous in intercrate mode (at least in the old solver) to avoid any worries about accidental impl overlap or something.

r? ```@lcnr``` cc ```@fee1-dead```
2024-10-29 03:11:40 -07:00
bors
2df8dbb1b3 Auto merge of #132277 - workingjubilee:rollup-5e6q6e4, r=workingjubilee
Rollup of 9 pull requests

Successful merges:

 - #130259 (Lower AST node id only once)
 - #131441 (Add a new trait `proc_macro::ToTokens`)
 - #132247 (stable_mir: Directly use types from rustc_abi)
 - #132249 (compiler: Add rustc_abi dependence to the compiler)
 - #132255 (Add `LayoutData::is_uninhabited` and use it)
 - #132258 ([rustdoc] Unify variant struct fields margins with struct fields)
 - #132260 (cg_llvm: Use a type-safe helper to cast `&str` and `&[u8]` to `*const c_char`)
 - #132261 (refactor: cleaner check to return None)
 - #132271 (Updating Fuchsia platform-support documentation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-29 07:32:45 +00:00
许杰友 Jieyou Xu (Joe)
6c93c65057 Delete tests/crashes/23707.rs because it's flaky
It's conditioned on `only-x86_64` because it doesn't reliably fail on
other platforms, it's optimization dependent and failed to ICE post-PGO
in
<https://github.com/rust-lang/rust/pull/132300#issuecomment-2443279042>.
Remove this test for now without prejudice against relanding the test in
a more reliable form.
2024-10-29 14:22:06 +08:00
Yuri Astrakhan
a645342720 More test for non-exhaustive C-like enums in FFI
Add a few more possibly false-positive tests for the `improper_ctypes` lint
2024-10-28 23:05:45 -04:00
bors
a9d17627d2 Auto merge of #128985 - GrigorenkoPV:instantly-dangling-pointer, r=Urgau
Lint against getting pointers from immediately dropped temporaries

Fixes #123613

## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`

## Questions:
- [ ]  Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? https://github.com/rust-lang/rust/pull/128985#issuecomment-2318714312

## Known limitations:

### False negatives[^fn]:

See the comments in `compiler/rustc_lint/src/dangling.rs`

1. Method calls that are not checked for:
   - `temporary_unsafe_cell.get()`
   - `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
   - `owning_temporary.field`
   - `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
   - `&raw [mut] temporary`
   - `&temporary as *(const|mut) _`
    - `ptr::from_ref(&temporary)` and friends

[^fn]: lint **should** be emitted, but **is not**

[^fp]: lint **should not** be emitted, but **is**
2024-10-29 00:24:07 +00:00
Michael Goulet
8b7b8e5f56 Hack out effects support for old solver 2024-10-28 21:42:14 +00:00
Jubilee
6ea83ffe2c
Rollup merge of #132258 - GuillaumeGomez:variant-structfields-margins, r=notriddle
[rustdoc] Unify variant struct fields margins with struct fields

As discussed in https://github.com/rust-lang/rust/pull/132220.

| before | after |
|-|-|
| ![image](https://github.com/user-attachments/assets/d8d8336d-7fe4-45fb-a5a5-36a4023223f5) | ![Screenshot from 2024-10-28 11-17-24](https://github.com/user-attachments/assets/9d0d9633-b857-45b4-9217-7d0d1aa8f770) |

r? ```@notriddle```
2024-10-28 10:18:51 -07:00
Jubilee
a24b3778d6
Rollup merge of #130259 - adwinwhite:lower-node-id-once, r=cjgillot
Lower AST node id only once

Fixes #96346.

I basically followed the given instructions except the inline part.

`lower_jump_destination` can't reuse local existing `HirId` due to unknown name resolution result so I created an additional mapping for labels.

r? ```@cjgillot```
2024-10-28 10:18:48 -07:00
bors
3f1be1ec7e Auto merge of #132145 - RalfJung:stdarch, r=Amanieu
bump stdarch

This lets us remove a hack from https://github.com/rust-lang/rust/pull/131349.

r? `@Amanieu`

try-job: test-various
2024-10-28 16:25:56 +00:00
Krasimir Georgiev
e4f793a1aa riscv-soft-abi-with-float-features.rs: adapt for LLVM 20 2024-10-28 13:43:03 +00:00
bors
9f57edf2e2 Auto merge of #132262 - matthiaskrgr:rollup-pcphi6l, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #131391 (Stabilize `isqrt` feature)
 - #132248 (rustc_transmute: Directly use types from rustc_abi)
 - #132252 (compiler: rename LayoutS to LayoutData)
 - #132253 (Known-bug test for `keyword_idents` lint not propagating to other files)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-28 13:32:57 +00:00
Pavel Grigorenko
c69894eaec New lint: dangling_pointers_from_temporaries 2024-10-28 14:16:05 +03:00
Matthias Krüger
2ca9b2cddd
Rollup merge of #132253 - Zalathar:keyword-idents-bug, r=jieyouxu
Known-bug test for `keyword_idents` lint not propagating to other files

Known-bug test for `keyword_idents` lint not propagating to other files when configured via attribute (#132218).
2024-10-28 12:14:59 +01:00
Ralf Jung
d066dfdb83 we can now enable the 'const stable fn must be stable' check 2024-10-28 11:48:39 +01:00
bors
32b17d56eb Auto merge of #132244 - jyn514:linker-refactors, r=bjorn3
fix various linker warnings

separated out from https://github.com/rust-lang/rust/pull/119286; this doesn't have anything user-facing, i just want to land these changes so i can stop rebasing them.

r? `@bjorn3`
2024-10-28 10:44:24 +00:00
Guillaume Gomez
26b6ccdbd7 Add GUI regression test for variant structfields margins 2024-10-28 11:16:38 +01:00
Adwin White
cb08e08722 Lower AST node id only once 2024-10-28 14:12:17 +08:00
Zalathar
dfafbc41d8 Known-bug test for keyword_idents lint not propagating to other files 2024-10-28 16:57:08 +11:00
许杰友 Jieyou Xu (Joe)
3e3feac7c3
Rollup merge of #132243 - compiler-errors:no-span, r=jieyouxu
Remove `ObligationCause::span()` method

I think it's an incredibly confusing footgun to expose both `obligation_cause.span` and `obligation_cause.span()`. Especially because `ObligationCause::span()` (the method) seems to just be hacking around a single quirk in the way we set up obligation causes for match arms.

First commit removes the need for that hack, with only one diagnostic span changing (but IMO not really getting worse -- I'd argue that it was already confusing).
2024-10-28 13:36:21 +08:00
许杰友 Jieyou Xu (Joe)
a9ee1d025b
Rollup merge of #132227 - compiler-errors:better-const-span, r=Nadrieril
Pass constness with span into lower_poly_trait_ref

Gives us a span to point at for ~const/const on non-const traits.

Split from #132209. r? Nadrieril
2024-10-28 13:36:20 +08:00
许杰友 Jieyou Xu (Joe)
5c14e3d54c
Rollup merge of #132220 - GuillaumeGomez:gui-test-struct-fields-margins, r=notriddle
Add GUI regression test for doc struct fields margins

Fixes #131402.

r? `@notriddle`
2024-10-28 13:36:19 +08:00
许杰友 Jieyou Xu (Joe)
20d2a546fa
Rollup merge of #132086 - estebank:long-types, r=jieyouxu
Tweak E0277 highlighting and "long type" path printing

Partially address #132013.

![Output from this PR for the repro case in #132013](https://github.com/user-attachments/assets/a073ba37-4adc-411e-81f7-6cb9a945ce3d)
2024-10-28 13:36:18 +08:00
asquared31415
6fc7ce43d2 Error on alignments greater than isize::MAX
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
2024-10-28 13:17:37 +08:00
Nicholas Nethercote
dd2b027d5d Tweak more warnings.
Much like the previous commit.

I think the removal of "the token" in each message is fine here. There
are many more error messages that mention tokens without saying "the
token" than those that do say it.
2024-10-28 14:20:28 +11:00
Nicholas Nethercote
a201fab208 Tweak expand_incomplete_parse warning.
By using `token_descr`, as is done for many other errors, we can get
slightly better descriptions in error messages, e.g.
"macro expansion ignores token `let` and any following" becomes
"macro expansion ignores keyword `let` and any tokens following".

This will be more important once invisible delimiters start being
mentioned in error messages -- without this commit, that leads to error
messages such as "error at ``" because invisible delimiters are
pretty printed as an empty string.
2024-10-28 14:12:45 +11:00
jyn
f1e5b365f0 port tests/ui/linkage-attr/framework to run-make
this makes it much easier to understand test failures.

before:
```
diff of stderr:

1 error: linking with `LINKER` failed: exit status: 1
2    |
-            ld: Undefined symbols:
4              _CFRunLoopGetTypeID, referenced from:
5            clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

after:
```
=== HAYSTACK ===
error: linking with `cc` failed: exit status: 1
  |
  = note: use `--verbose` to show all linker arguments
  = note: Undefined symbols for architecture arm64:
            "_CFRunLoopGetTypeID", referenced from:
                main::main::hbb553f5dda62d3ea in main.main.d17f5fbe6225cf88-cgu.0.rcgu.o
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to 1 previous error

=== NEEDLE ===
_CFRunLoopGetTypeID\.?, referenced from:
thread 'main' panicked at /Users/jyn/git/rust-lang/rust/tests/run-make/linkage-attr-framework/rmake.rs:22:10:
needle was not found in haystack
```

this also fixes a failure related to missing whitespace; we don't actually care about whitespace in this test.
2024-10-27 21:23:28 -04:00
jyn
3141a65d25 give a better error for tuple structs in derive(Diagnostic) 2024-10-27 21:23:28 -04:00
Michael Goulet
2507e83d7b Stop using the whole match expr span for an arm's obligation span 2024-10-27 22:48:03 +00:00
bors
df4ca44d3f Auto merge of #132237 - matthiaskrgr:rollup-ulogwtd, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #132043 (Simplify param handling in `resolve_bound_vars`)
 - #132214 (Cleanup: Move an impl-Trait check from AST validation to AST lowering)
 - #132221 (Clean up some comments on lint implementation)
 - #132228 (Revert "ci update freebsd version proposal, freebsd 12 being eol.")
 - #132234 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-27 20:00:19 +00:00
Matthias Krüger
574a8ba6af
Rollup merge of #132214 - fmease:mv-impl-trait-val-paths, r=compiler-errors
Cleanup: Move an impl-Trait check from AST validation to AST lowering

Namely the one that rejects `impl Trait` in qself types and non-final path segments.
There's no good reason to perform this during AST validation.
We have better infrastructure in place in the AST lowerer (`ImplTraitContext`).
This shaves off a lot of code.
We now lower `impl Trait` in bad positions to `{type error}` which allows us to
remove a special case from HIR ty lowering.

Coincidentally fixes #126725. Well, it only *masks* it by passing `{type error}` to HIR analysis instead of a "bad" opaque. I was able to find a new reproducer for it. See the issue.
2024-10-27 19:49:07 +01:00
bors
81d6652e74 Auto merge of #131284 - dingxiangfei2009:rename-smart-ptr-to-coerce-referent, r=compiler-errors
Rename macro `SmartPointer` to `CoercePointee`

As per resolution #129104 we will rename the macro to better reflect the technical specification of the feature and clarify the communication.

- `SmartPointer` is renamed to `CoerceReferent`
- `#[pointee]` attribute is renamed to `#[referent]`
- `#![feature(derive_smart_pointer)]` gate is renamed to `#![feature(derive_coerce_referent)]`.
- Any mention of `SmartPointer` in the file names are renamed accordingly.

r? `@compiler-errors`

cc `@nikomatsakis` `@Darksonn`
2024-10-27 17:04:12 +00:00
Guillaume Gomez
c50bfda34f Add GUI regression test for doc struct fields margins 2024-10-27 11:26:45 +01:00
León Orell Valerian Liehr
442f39582d
Move an impl-Trait check from AST validation to AST lowering 2024-10-27 07:41:52 +01:00
bors
de7cef75be Auto merge of #132213 - workingjubilee:rollup-tg1g3l5, r=workingjubilee
Rollup of 4 pull requests

Successful merges:

 - #132123 (allow type-based search on foreign functions)
 - #132183 (Fix code HTML items making big blocks if too long)
 - #132192 (expand: Stop using artificial `ast::Item` for macros loaded from metadata)
 - #132205 (docs: Correctly link riscv32e from platform-support.md)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-27 05:56:58 +00:00
Jubilee
b80593995d
Rollup merge of #132183 - GuillaumeGomez:code-in-docblock, r=notriddle
Fix code HTML items making big blocks if too long

Encountered this bug randomly where `code` item in docblocks would look like this:

![Screenshot from 2024-10-26 15-44-46](https://github.com/user-attachments/assets/a9c1df9d-5007-49eb-a7dd-a2c381b2511e)

With this fix it looks like this:

![image](https://github.com/user-attachments/assets/ea918595-5434-4781-b68c-6abd38689365)

r? ``@notriddle``
2024-10-26 21:58:39 -07:00
Jubilee
05f784c955
Rollup merge of #132123 - lolbinarycat:rustdoc-search-foreign-func, r=notriddle
allow type-based search on foreign functions

fixes https://github.com/rust-lang/rust/issues/131804

preferably will be merged after #129708, but that may take a while to be approved due to being a new feature, whereas this is definitely a bug, and should be fixed.
2024-10-26 21:58:39 -07:00
bors
be33e4f3d6 Auto merge of #132167 - Zalathar:llvm-wrappers, r=jieyouxu
Replace some LLVMRust wrappers with calls to the LLVM C API

This PR removes the LLVMRust wrapper functions for getting/setting linkage and visibility, and replaces them with direct calls to the corresponding functions in LLVM's C API.

To make this convenient and sound, two pieces of supporting code have also been added:
- A simple proc-macro that derives `TryFrom<u32>` for fieldless enums
- A wrapper type for C enum values returned by LLVM functions, to ensure soundness if LLVM returns an enum value we don't know about

In a few places, the use of safe wrapper functions means that an `unsafe` block is no longer needed, so the affected code has changed its indentation level.
2024-10-27 03:24:54 +00:00
Michael Howell
1819b4fa23 rustdoc: make doctest span tweak a 2024 edition change
Fixes #132203

This is a compatibility hack, because I think the new behavior is better.
When an A `include_str!` B, and B `include_str!` C, the path to C should
be resolved relative to B, not A. That's how `include!` itself works,
so that's how `include_str!` with should work.
2024-10-26 17:56:38 -07:00
bors
f7cf41c973 Auto merge of #131900 - mrkajetanp:target-feature-pauth-lr, r=Amanieu
rustc_target: Add pauth-lr aarch64 target feature

Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.

r? `@Amanieu`
2024-10-27 00:09:49 +00:00
Michael Goulet
bd95695b94 Pass constness with span into lower_poly_trait_ref 2024-10-26 20:54:38 +00:00
Guillaume Gomez
88f4425dd2 Update GUI test 2024-10-26 20:40:59 +02:00
Michael Goulet
6ab87f8238 Collect item bounds for RPITITs from trait where clauses just like associated types 2024-10-26 17:38:08 +00:00
bors
4d88de2acd Auto merge of #125116 - blyxyas:ignore-allowed-lints-final, r=cjgillot
(Big performance change) Do not run lints that cannot emit

Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)

So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`

As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)

Fixes #106983
2024-10-26 16:37:43 +00:00
许杰友 Jieyou Xu (Joe)
50e78b8b3c
Rollup merge of #132180 - Urgau:ast_pretty-unsafe-attr, r=compiler-errors
Print unsafety of attribute in AST pretty print

This PR fixes the AST pretty print, which was missing the unsafety for unsafe attributes.

Related to https://github.com/rust-lang/rust/pull/131558#discussion_r1807736204
2024-10-26 22:01:14 +08:00
许杰友 Jieyou Xu (Joe)
bafe790a2d
Rollup merge of #132169 - fee1-dead-contrib:consttraitsck, r=compiler-errors
Deny calls to non-`#[const_trait]` methods in MIR constck

This is a (potentially temporary) fix that closes off the mismatch in assumptions between MIR constck and typeck which does the const traits checking. Before this PR, MIR constck assumed that typeck correctly handled all calls to trait methods in const contexts if effects is enabled. That is not true because typeck only correctly handles callees that are const. For non-const callees (such as methods in a non-const_trait), typeck had never created an error.

45089ec19e/compiler/rustc_hir_typeck/src/callee.rs (L876-L877)

I called this potentially temporary because the const checks could be moved to HIR entirely. Alongside the recent refactor in const stability checks where that component could be placed would need more discussion. (cc ```@compiler-errors``` ```@RalfJung)```

Tests are updated, mainly due to traits not being const in core, so tests that call them correctly error.

This fixes https://github.com/rust-lang/project-const-traits/issues/12.
2024-10-26 22:01:13 +08:00
Guillaume Gomez
ae66380da0 Add GUI regression test for code in doc blocks 2024-10-26 15:45:17 +02:00
Urgau
f5b6f938ce Print unsafety of attribute in AST unpretty 2024-10-26 13:33:36 +02:00
Urgau
f249fdd962 Add AST unpretty test for unsafe attribute 2024-10-26 13:31:24 +02:00
Zalathar
144a12acdd Add a macro that derives TryFrom<u32> for fieldless enums 2024-10-26 20:19:53 +11:00
bors
ae4c6b6640 Auto merge of #132152 - lqd:revert-127731, r=compiler-errors
Revert #127731 "Emit error when calling/declaring functions with unavailable …"

This reverts #127731 due to the unexpected [perf regressions](https://github.com/rust-lang/rust/pull/127731#issuecomment-2438687094) and to give time to mitigate the regressions before re-landing it.

r? `@RalfJung` cc `@veluca93`
2024-10-26 04:24:31 +00:00
Deadbeef
f2f67232a5 Deny calls to non-#[const_trait] methods in MIR constck 2024-10-26 11:35:56 +08:00
bors
54761cb3e8 Auto merge of #131349 - RalfJung:const-stability-checks, r=compiler-errors
Const stability checks v2

The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage:
- It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention.
- The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check.

Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories.

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required.

Also see the updated dev-guide at https://github.com/rust-lang/rustc-dev-guide/pull/2098.

I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`.

### Open question

There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]`  functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]`  will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics.

I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics.

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
Part of https://github.com/rust-lang/rust/issues/129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown)
Fixes https://github.com/rust-lang/rust/issues/131073 by making it so that const-stable functions are always stable

try-job: test-various
2024-10-25 23:29:40 +00:00
Rémy Rakic
bd8477b562 Revert "Emit error when calling/declaring functions with unavailable vectors."
This reverts commit 5af56cac38.
2024-10-25 20:42:09 +00:00
Michael Goulet
ad76564900 Ensure that resume arg outlives region bound for coroutines 2024-10-25 20:16:52 +00:00
bors
b188577f14 Auto merge of #131917 - jieyouxu:rmake-clang, r=Kobzol
Run the full stage 2 `run-make` test suite in `x86_64-gnu-debug`

Run the full `run-make` test suite in the `x86_64-gnu-debug` CI job. This is currently the *only* CI job where `//@ needs-force-clang-based-test` will be satisfied, so some `run-make` tests will literally never be run otherwise. Before this PR, the CI job only ran `run-make` tests which contains the substring `clang` in its test name, which is both (1) a footgun because it's very easy to forget and (2) it masks tests that would otherwise fail (even failing to compile) because the test is skipped if doesn't have a `clang` in its test name.

With the environment of `x86_64-gnu-debug`, two `run-make` tests failed before this PR:

1. `tests/run-make/issue-84395-lto-embed-bitcode/rmake.rs`: this was broken for a long time because `objcopy` in llvm bin tools was renamed to `llvm-objcopy`. This test was converted into a rmake.rs test, rather straight forward.
2. `tests/run-make/cross-lang-lto-riscv-abi/rmake.rs`: this was broken for a long time and never worked. The old version inspected human-readable output of `llvm-readobj --file-header` looking for substring `EF_RISCV_FLOAT_ABI_DOUBLE`, but the human-readable output will only contain something like `Flags: 0x5, RVC, double-float ABI`, hence it will never match. This test was fixed by instead using the `object` crate to actually decode the ELF headers looking for the specific `e_flags` based on reading the RISCV ELF psABI docs.

This PR is best reviewed commit-by-commit, two commits setup the support library for functionality and two commits are for each of the failing `run-make` tests.

I had to bump the `x86_64-gnu-debug` job to be ran with a runner with larger disk space.

Part of #132034.

try-job: x86_64-gnu-debug
2024-10-25 18:33:17 +00:00
Ralf Jung
36dda4571d add a HACK to allow stdarch migration 2024-10-25 20:31:40 +02:00
Ralf Jung
a0215d8e46 Re-do recursive const stability checks
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features

This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.

Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.

The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.

Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
2024-10-25 20:31:40 +02:00
Esteban Küber
aa82fd6d1d Tweak highlighting when trait is available for different type
When printing

```
  = help: the trait `chumsky::private::ParserSealed<'_, &'a str, ((), ()), chumsky::extra::Full<EmptyErr, (), ()>>` is implemented for `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>`
  = help: for that trait implementation, expected `((), ())`, found `()`
```

Highlight only the `expected` and `found` types, instead of the full type in the first `help`.
2024-10-25 18:06:39 +00:00
Esteban Küber
24ac777a64 Add test for #132013 2024-10-25 18:06:36 +00:00
binarycat
09773b4f24 allow type-based search on foreign functions
fixes https://github.com/rust-lang/rust/issues/131804
2024-10-25 12:19:04 -05:00
bors
6faf0bd3e5 Auto merge of #127731 - veluca93:abi_checks, r=RalfJung
Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in https://github.com/rust-lang/lang-team/issues/235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the [nomination comment](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.

r? RalfJung

Part of https://github.com/rust-lang/rust/issues/116558
2024-10-25 15:17:47 +00:00
bors
45089ec19e Auto merge of #131207 - davidtwco:pac-ret-lto-test, r=Mark-Simulacrum
ci: aarch64-gnu-debug job

- Adds a new CI job which checks that the compiler builds with `--enable-debug` and tests that `needs-force-clang-based-tests` pass (where cross-language LTO is tested).
- Add a test confirming that `-Zbranch-protection=pac-ret` and cross-language LTO work together.

r? `@Mark-Simulacrum`

try-job: aarch64-gnu-debug
2024-10-25 12:36:24 +00:00
bors
97ae1df8aa Auto merge of #132128 - workingjubilee:rollup-uwqp2i2, r=workingjubilee
Rollup of 4 pull requests

Successful merges:

 - #131457 (Expand `ptr::fn_addr_eq()` documentation.)
 - #132085 (Update StableMIR doc to reflect current status)
 - #132118 (Add support for `~const` item bounds)
 - #132125 (coverage: Emit LLVM intrinsics using the normal helper method)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-25 07:42:32 +00:00
Luca Versari
5af56cac38 Emit error when calling/declaring functions with unavailable vectors.
On some architectures, vector types may have a different ABI when
relevant target features are enabled.

As discussed in https://github.com/rust-lang/lang-team/issues/235, this
turns out to very easily lead to unsound code.

This commit makes it an error to declare or call functions using those
vector types in a context in which the corresponding target features are
disabled, if using an ABI for which the difference is relevant.
2024-10-25 08:46:40 +02:00
Jubilee
3c6d34f4c4
Rollup merge of #132118 - compiler-errors:tilde-const-item-bounds, r=lcnr
Add support for `~const` item bounds

Supports the only missing capability of `~const` associated types that I can think of now (this is obviously excluding `~const` opaques, which I see as an extension to this; I'll probably do that next).

r? ``@lcnr`` mostly b/c it changes candidate assembly, or reassign

cc ``@fee1-dead``
2024-10-24 23:23:56 -07:00
bors
017ae1b21f Auto merge of #132105 - GuillaumeGomez:doctest-nested-main, r=notriddle
[rustdoc] Do not consider nested functions as main function even if named `main` in doctests

Fixes #131893.

If a nested function is called `main`, it is not considered as the entry point of the program. Therefore, doctests should not consider such functions as such either.

r? `@notriddle`
2024-10-25 05:11:05 +00:00
bors
788202a2ce Auto merge of #132121 - workingjubilee:rollup-yrtn33e, r=workingjubilee
Rollup of 6 pull requests

Successful merges:

 - #131851 ([musl] use posix_spawn if a directory change was requested)
 - #132048 (AIX: use /dev/urandom for random implementation )
 - #132093 (compiletest: suppress Windows Error Reporting (WER) for `run-make` tests)
 - #132101 (Avoid using imports in thread_local_inner! in static)
 - #132113 (Provide a default impl for Pattern::as_utf8_pattern)
 - #132115 (rustdoc: Extend fake_variadic to "wrapped" tuples)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-25 01:18:09 +00:00
Michael Goulet
3bad5014c9 Add support for ~const item bounds 2024-10-24 23:43:31 +00:00
Jubilee
3549dbb149
Rollup merge of #132115 - bash:rustdoc-fake-variadic-wrapper, r=GuillaumeGomez,notriddle
rustdoc: Extend fake_variadic to "wrapped" tuples

This allows impls such as `impl QueryData for OneOf<(T,)>` to be displayed as variadic: `impl QueryData for OneOf<(T₁, T₂, …, Tₙ)>`.

See question on [zulip](https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Make.20.60.23.5Bdoc.28fake_variadic.29.5D.60.20more.20useful).
2024-10-24 15:53:36 -07:00
bors
a93c1718c8 Auto merge of #132116 - matthiaskrgr:rollup-3a0ia4r, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #131790 (Document textual format of SocketAddrV{4,6})
 - #131983 (Stabilize shorter-tail-lifetimes)
 - #132097 (sanitizer.md: LeakSanitizer is not supported on aarch64 macOS)
 - #132107 (Remove visit_expr_post from ast Visitor)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-24 20:28:20 +00:00
Guillaume Gomez
aab2b6747d Add regression test for #131893 2024-10-24 21:35:15 +02:00
Matthias Krüger
91c025d741
Rollup merge of #131983 - dingxiangfei2009:stabilize-shorter-tail-lifetimes, r=lcnr
Stabilize shorter-tail-lifetimes

Close #131445
Tracked by #123739

We found a test case `tests/ui/drop/drop_order.rs` that had not been covered by the change. The test fixture is fixed now with the correct expectation.
2024-10-24 19:39:14 +02:00
bors
1d4a7670d4 Auto merge of #131985 - compiler-errors:const-pred, r=fee1-dead
Represent trait constness as a distinct predicate

cc `@rust-lang/project-const-traits`
r? `@ghost` for now

Also mirrored everything that is written below on this hackmd here: https://hackmd.io/`@compiler-errors/r12zoixg1l`

# Tl;dr:

* This PR removes the bulk of the old effect desugaring.
* This PR reimplements most of the effect desugaring as a new predicate and set of a couple queries. I believe it majorly simplifies the implementation and allows us to move forward more easily on its implementation.

I'm putting this up both as a request for comments and a vibe-check, but also as a legitimate implementation that I'd like to see land (though no rush of course on that last part).

## Background

### Early days

Once upon a time, we represented trait constness in the param-env and in `TraitPredicate`. This was very difficult to implement correctly; it had bugs and was also incomplete; I don't think this was anyone's fault though, it was just the limit of experimental knowledge we had at that point.

Dealing with `~const` within predicates themselves meant dealing with constness all throughout the trait solver. This was difficult to keep track of, and afaict was not handled well with all the corners of candidate assembly.

Specifically, we had to (in various places) remap constness according to the param-env constness:

574b64a97f/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1498)

This was annoying and manual and also error prone.

### Beginning of the effects desugaring

Later on, #113210 reimplemented a new desugaring for const traits via a `<const HOST: bool>` predicate. This essentially "reified" the const checking and separated it from any of the remapping or separate tracking in param-envs. For example, if I was in a const-if-const environment, but I wanted to call a trait that was non-const, this reification would turn the constness mismatch into a simple *type* mismatch of the effect parameter.

While this was a monumental step towards straightening out const trait checking in the trait system, it had its own issues, since that meant that the constness of a trait (or any item within it, like an associated type) was *early-bound*. This essentially meant that `<T as Trait>::Assoc` was *distinct* from `<T as ~const Trait>::Assoc`, which was bad.

### Associated-type bound based effects desugaring

After this, #120639 implemented a new effects desugaring. This used an associated type to more clearly represent the fact that the constness is not an input parameter of a trait, but a property that could be computed of a impl. The write-up linked in that PR explains it better than I could.

However, I feel like it really reached the limits of what can comfortably be expressed in terms of associated type and trait calculus. Also, `<const HOST: bool>` remains a synthetic const parameter, which is observable in nested items like RPITs and closures, and comes with tons of its own hacks in the astconv and middle layer.

For example, there are pieces of unintuitive code that are needed to represent semantics like elaboration, and eventually will be needed to make error reporting intuitive, and hopefully in the future assist us in implementing built-in traits (eventually we'll want something like `~const Fn` trait bounds!).

elaboration hack: 8069f8d17a/compiler/rustc_type_ir/src/elaborate.rs (L133-L195)

trait bound remapping hack for diagnostics: 8069f8d17a/compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs (L2370-L2413)

I want to be clear that I don't think this is a issue of implementation quality or anything like that; I think it's simply a very clear sign that we're using types and traits in a way that they're not fundamentally supposed to be used, especially given that constness deserves to be represented as a first-class concept.

### What now?

This PR implements a new desugaring for const traits. Specifically, it introduces a `HostEffect` predicate to represent the obligation an impl is const, rather than using associated type bounds and the compat trait that exists for effects today.

### `HostEffect` predicate

A `HostEffect` clause has two parts -- the `TraitRef` we're trying to prove, and a `HostPolarity::{Maybe, Const}`.

`HostPolarity::Const` corresponds to `T: const Trait` bounds, which must *always* be proven as const, and which can be written in any context. These are lowered directly into the predicates of an item, since they're not "context-specific".

On the other hand, `HostPolarity::Maybe` corresponds to `T: ~const Trait` bounds which must only exist in a conditionally-const context like a method in a `#[const_trait]`, or a `const fn` free function. We do not lower these immediately into the predicates of an item; instead, we collect them into a new query called the **`const_conditions`**. These are the set of trait refs that we need to prove have const implementations for an item to be const.

Notably, they're represented as bare (poly) trait refs because they are meant to be paired back together with a `HostPolarity` when they're being registered in typeck (see next section).

For example, given:

```rust
const fn foo<T: ~const A + const B>() {}
```

`foo`'s const conditions would contain `T: A`, but not `T: B`. On the flip side, foo's predicates (`predicates_of`) query would contain `HostEffect(T: B, HostPolarity::Const)` but not `HostEffect(T: A, HostPolarity::Maybe)` since we don't need to prove that predicate in a non-const environment (and it's not even the right predicate to prove in an unconditionally const environment).

### Type checking const bodies

When type checking bodies in HIR, when we encounter a call expression, we additionally register the callee item's const conditions with the `HostPolarity` from the body we're typechecking (`Const` for unconditionally const things like `const`/`static` items, and `Maybe` for conditionally const things like const fns; and we don't register `HostPolarity` predicates for non-const bodies).

When type-checking a conditionally const body, we augment its param-env with `HostEffect(..., Maybe)` predicates.

### Checking that const impls are WF

We extend the logic in `compare_method_predicate_entailment` to also check the const-conditions of the impl method, to make sure that we error for:

```rust
#[const_trait] Bar {}
#[const_trait] trait Foo {
    fn method<T: Bar>();
}

impl Foo for () {
    fn method<T: ~const Bar>() {} // stronger assumption!
}
```

We also extend the WF check for impls to register the const conditions of the trait that is being implemented. This is to make sure we error for:

```rust
#[const_trait] trait Bar {}
#[const_trait] trait Foo<T> where T: ~const Bar {}

impl<T> const Foo<T> for () {}
//~^ `T: ~const Bar` is missing!
```

### Proving a `HostEffect` predicate

We have several ways of proving a `HostEffect` predicate:

1. Matching a `HostEffect` predicate from the param-env
2. From an impl - we do impl selection very similar to confirming a trait goal, except we filter for only const impls, and we additionally register the impl's const conditions (i.e. the impl's `~const` where clauses).

Later I expect that we will add more built-in implementations for things like `Fn`.

## What next?

After this PR, I'd like to split out the work more so it can proceed in parallel and probably amongst others that are not me.

* Register `HostEffect` goal for places in HIR typeck that correspond to call terminators, like autoderef.
* Make traits in libstd const again.
    * Probably need to impl host effect preds in old solver.
* Implement built-in `HostEffect` rules for traits like `Fn`.
* Rip out const checking from MIR altogether.

## So what?

This ends up being super convenient basically everywhere in the compiler. Due to the design of the new trait solver, we end up having an almost parallel structure to the existing trait and projection predicates for assembling `HostEffect` predicates; adding new candidates and especially new built-in implementations is now basically trivial, and it's quite straightforward to understand the confirmation logic for these predicates.

Same with diagnostics reporting; since we have predicates which represent the obligation to prove an impl is const, we can simplify and make these diagnostics richer without having to write a ton of logic to intercept and rewrite the existing `Compat` trait errors.

Finally, it gives us a much more straightforward path for supporting the const effect on the old trait solver. I'm personally quite passionate about getting const trait support into the hands of users without having to wait until the new solver lands[^1], so I think after this PR lands we can begin to gauge how difficult it would be to implement constness in the old trait solver too. This PR will not do this yet.

[^1]: Though this is not a prerequisite or by any means the only justification for this PR.
2024-10-24 17:33:42 +00:00
Tau Gärtli
4e48768908
rustdoc: Extend fake_variadic to "wrapped" tuples
This allows impls such as `impl QueryData for OneOf<(T,)>`
to be displayed as variadic: `impl QueryData for OneOf<(T₁, T₂, …, Tₙ)>`.

See question on zulip:
<https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Make.20.60.23.5Bdoc.28fake_variadic.29.5D.60.20more.20useful>
2024-10-24 18:50:55 +02:00
David Wood
352b505f80
tests: add pac-ret + cross-language lto test
Add a test confirming that `-Zbranch-protection=pac-ret` and
cross-language LTO work together.
2024-10-24 16:49:12 +01:00
David Wood
105961ecb4
ci: add aarch64-gnu-debug job
Adds a new CI job which checks that the compiler builds with
`--enable-debug` and tests that `needs-force-clang-based-tests` pass
(where cross-language LTO is tested).
2024-10-24 16:49:12 +01:00
bors
f61306d47b Auto merge of #123550 - GnomedDev:remove-initial-arc, r=Noratrieb
Remove the `Arc` rt::init allocation for thread info

Removes an allocation pre-main by just not storing anything in std:🧵:Thread for the main thread.
- The thread name can just be a hard coded literal, as was done in #123433.
- Storing ThreadId and Parker in a static that is initialized once at startup. This uses SyncUnsafeCell and MaybeUninit as this is quite performance critical and we don't need synchronization or to store a tag value and possibly leave in a panic.
2024-10-24 13:35:50 +00:00
Michael Goulet
0f5a47d088 Be better at enforcing that const_conditions is only called on const items 2024-10-24 09:46:36 +00:00
Michael Goulet
25c9253379 Add tests 2024-10-24 09:46:36 +00:00
Michael Goulet
779b3943d3 Add next-solver to more effects tests 2024-10-24 09:46:36 +00:00
Michael Goulet
cde29b9ec9 Implement const effect predicate in new solver 2024-10-24 09:46:36 +00:00
Michael Goulet
a16d491054 Remove associated type based effects logic 2024-10-24 09:46:36 +00:00
Matthias Krüger
0470728e94
Rollup merge of #132084 - compiler-errors:param-env-with-err, r=lcnr,estebank
Consider param-env candidates even if they have errors

I added this logic in https://github.com/rust-lang/rust/pull/106309, but frankly I don't know why -- the logic was a very large hammer. It seems like recent changes to error tainting has made that no longer necessary.

Ideally we'd rework the way we handle error reporting in all of candidate assembly to be a bit more responsible; we're just suppressing candidates all willy-nilly and it leads to mysterious *other* errors cropping up, like the one that #132082 originally wanted to fix.

**N.B.** This has the side-effect of turning a failed resolution like `where Missing: Sized` into a trivial where clause that matches all types, but also I don't think it really matters?

I'm putting this up as an alternative to #132082, since that PR doesn't address the case when one desugars the APIT into a regular type param.

r? lcnr vibeck
2024-10-24 10:35:40 +02:00
Matthias Krüger
96558580ac
Rollup merge of #131906 - notriddle:notriddle/spacing, r=GuillaumeGomez
rustdoc: adjust spacing and typography in header

Fixes #131589

Preview: https://notriddle.com/rustdoc-html-demo-12/spacing/std/index.html

| Before | After |
|--|--|
| ![image](https://github.com/user-attachments/assets/b5c5132d-1e5e-402e-ba19-1dea9e70ea6f) | ![image](https://github.com/user-attachments/assets/72570b93-bb16-4553-9da7-fc4f29b98873)
| ![image](https://github.com/user-attachments/assets/264983f0-5aec-4120-8a03-f62e52d4360d) | ![image](https://github.com/user-attachments/assets/b6925945-95e6-4858-8e91-4cfd90c164f0)
| ![image](https://github.com/user-attachments/assets/df96bfe7-195d-4aaf-97f1-a45ade34cab2) | ![image](https://github.com/user-attachments/assets/c6fe2d57-bd8a-42aa-b3cf-4f635809b9b4)
| ![image](https://github.com/user-attachments/assets/7519faa5-d6b2-41ba-9d95-6000d1dd89d1) | ![image](https://github.com/user-attachments/assets/7233c2d6-82d9-4820-bb63-dc4776a34601)

First of all, we put 4px additional margin below the search box, and 4px margin below the header to balance it out.

The bigger problem we have to solve is making the lines look logically spaced. This is troublesome, because Fira Sans (the typeface we use here) wants to look good on average, and to avoid breaking, with text that uses [ascenders and descenders](https://www.w3.org/TR/css-inline-3/images/text-edge.png). If the text we're putting in happens to not have any, things look weird (strictly speaking, there’s hand-tuning here, because the Copy Path button messes with stuff, but the overall point is that there is no true, one perfect layout).

In order to play nicely with the font, I've tweaked the text to use that space. The word "Source" for the link is now capitalized, and the Since version number now uses oldstyle nums with descenders.
2024-10-24 10:35:39 +02:00
Matthias Krüger
93bf791e8b
Rollup merge of #129248 - compiler-errors:raw-ref-deref, r=nnethercote
Taking a raw ref (`&raw (const|mut)`) of a deref of pointer (`*ptr`) is always safe

T-opsem decided in https://github.com/rust-lang/reference/pull/1387 that `*ptr` is only unsafe if the place is accessed. This means that taking a raw ref of a deref expr is always safe, since it doesn't constitute a read.

This also relaxes the `DEREF_NULLPTR` lint to stop warning in the case of raw ref of a deref'd nullptr, and updates its docs to reflect that change in the UB specification.

This does not change the behavior of `addr_of!((*ptr).field)`, since field projections still require the projection is in-bounds.

I'm on the fence whether this requires an FCP, since it's something that is guaranteed by the reference you could ostensibly call this a bugfix since we were counting truly safe operations as unsafe. Perhaps someone on opsem has a strong opinion? cc `@rust-lang/opsem`
2024-10-24 10:35:39 +02:00
Duncan Proctor
10b60eba9b add third help hint to diagnostic error E0027 2024-10-24 03:17:28 -04:00
Stuart Cook
7e2bbc30b3
Rollup merge of #132088 - compiler-errors:extern-static, r=jieyouxu
Print safety correctly in extern static items

Fixes #132080

r? spastorino or anyone really
2024-10-24 14:19:58 +11:00
Stuart Cook
f7f411dd4e
Rollup merge of #131930 - clubby789:revision-cfg-collide, r=jieyouxu
Don't allow test revisions that conflict with built in cfgs

Fixes #128964

Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅
2024-10-24 14:19:56 +11:00
Stuart Cook
4b02d642dd
Rollup merge of #131909 - clubby789:enum-overflow-cast, r=compiler-errors
Prevent overflowing enum cast from ICEing

Fixes #131902
2024-10-24 14:19:56 +11:00
Stuart Cook
4c0bab3192
Rollup merge of #131898 - lukas-code:ptr-cast-cleanup, r=compiler-errors
minor `*dyn` cast cleanup

Small follow-up to https://github.com/rust-lang/rust/pull/130234 to remove a redundant check and clean up comments. No functional changes.

Also, explain why casts cannot drop the principal even though coercions can, and add a test because apparently we didn't have one already.

r? `@WaffleLapkin` or `@compiler-errors`
2024-10-24 14:19:55 +11:00
Stuart Cook
ad43be310f
Rollup merge of #131756 - compiler-errors:deeply-normalize-type-err, r=lcnr
Deeply normalize `TypeTrace` when reporting type error in new solver

Normalize the values that come from the `TypeTrace` for various type mismatches.

Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe...

r? lcnr
2024-10-24 14:19:55 +11:00
Stuart Cook
9c73bcfa8d
Rollup merge of #130225 - adetaylor:rename-old-receiver, r=wesleywiser
Rename Receiver -> LegacyReceiver

As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? `@wesleywiser`
2024-10-24 14:19:53 +11:00
Michael Goulet
4217b8702d Deeply normalize type trace in type error reporting 2024-10-24 02:48:28 +00:00
Michael Goulet
d8dc31fd3d Consider param-env candidates even if they have errors 2024-10-24 01:48:44 +00:00
Michael Goulet
4e1b3ab0e7 Print safety correctly in extern static items 2024-10-24 00:41:27 +00:00
Michael Howell
a53655a023 rustdoc: adjust spacing and typography in header 2024-10-23 19:15:23 -04:00
bors
b8bb2968ce Auto merge of #132079 - fmease:rollup-agrd358, r=fmease
Rollup of 9 pull requests

Successful merges:

 - #130991 (Vectorized SliceContains)
 - #131928 (rustdoc: Document `markdown` module.)
 - #131955 (Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64)
 - #131979 (Minor tweaks to `compare_impl_item.rs`)
 - #132036 (Add a test case for #131164)
 - #132039 (Specialize `read_exact` and `read_buf_exact` for `VecDeque`)
 - #132060 ("innermost", "outermost", "leftmost", and "rightmost" don't need hyphens)
 - #132065 (Clarify documentation of `ptr::dangling()` function)
 - #132066 (Fix a typo in documentation of `pointer::sub_ptr()`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-23 22:28:57 +00:00
Ding Xiang Fei
6d569f769c
stabilize if_let_rescope 2024-10-24 04:33:14 +08:00
León Orell Valerian Liehr
8b1141a5c3
Rollup merge of #132060 - joshtriplett:innermost-outermost, r=jieyouxu
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens

These are all standard dictionary words and don't require hyphenation.

-----

Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
2024-10-23 22:11:05 +02:00
León Orell Valerian Liehr
f3d4887a4a
Rollup merge of #132036 - DianQK:test-131164, r=jieyouxu
Add a test case for #131164

The upstream has already been fixed, but it won't be backported to LLVM 19.

r? jieyouxu or compiler

try-job: x86_64-gnu-stable
2024-10-23 22:11:04 +02:00
León Orell Valerian Liehr
a144561608
Rollup merge of #131955 - SpriteOvO:riscv-int-arg-attr, r=workingjubilee
Set `signext` or `zeroext` for integer arguments on RISC-V and LoongArch64

This PR contains 3 commits:

- the first one introduces a new function `adjust_for_rust_abi` in `rustc_target`, and moves the x86 specific adjustment code into it;
- the second one adds RISC-V specific adjustment code into it, which sets `signext` or `zeroext` attribute for integer arguments.
- **UPDATE**: added the 3rd commit to apply the same adjustment for LoongArch64.
2024-10-23 22:11:03 +02:00
Ding Xiang Fei
fd36b3a4a8
s/SmartPointer/CoerceReferent/g
move derive_smart_pointer into removed set
2024-10-24 02:14:09 +08:00
clubby789
2e3091d66c Don't allow test revisions that conflict with built in cfgs 2024-10-23 18:05:27 +00:00
Ding Xiang Fei
0689b2139f
stabilize shorter-tail-lifetimes 2024-10-24 01:56:08 +08:00
León Orell Valerian Liehr
03cb7de189
Rollup merge of #131487 - graydon:wasm32v1-none, r=alexcrichton
Add wasm32v1-none target (compiler-team/#791)

This is a preliminary implementation of the MCP discussed in [compiler-team#791](https://github.com/rust-lang/compiler-team/issues/791). It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.
2024-10-23 17:24:31 +02:00
DianQK
6570a6fe92
Add a test case for #131164 2024-10-23 19:01:38 +08:00
Josh Triplett
ecdc2441b6 "innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
2024-10-23 02:45:24 -07:00
Graydon Hoare
e14d6d8314
Add wasm32v1-none target (compiler-team/#791) 2024-10-22 23:04:44 -07:00