Commit Graph

12140 Commits

Author SHA1 Message Date
Oneirical
8a09f2231d rewrite extern-fn-generic to rmake 2024-07-19 12:27:47 -04:00
Oneirical
1a4fba5eb0 rewrite c-static-rlib to rmake 2024-07-19 12:27:47 -04:00
Oneirical
1ae1ab8215 rewrite c-static-dylib to rmake 2024-07-19 12:27:47 -04:00
Oneirical
5e55f07cc0 rewrite and rename issue-28595 to rmake 2024-07-19 12:27:46 -04:00
Oneirical
5b1860a24e rewrite return-non-c-like-enum-from-c to rmake 2024-07-19 12:27:26 -04:00
bors
0cd01aac6a Auto merge of #127969 - matthiaskrgr:rollup-nhxmwhn, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #112328 (Feat. adding ext that returns change_time)
 - #126199 (Add `isqrt` to `NonZero<uN>`)
 - #127856 (interpret: add sanity check in dyn upcast to double-check what codegen does)
 - #127934 (Improve error when a compiler/library build fails in `checktools.sh`)
 - #127960 (Cleanup dll/exe filename calculations in `run_make_support`)
 - #127963 (Fix display of logo "border")
 - #127967 (Disable run-make/split-debuginfo test for RISC-V 64)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 16:13:37 +00:00
Matthias Krüger
73db4e32f3
Rollup merge of #127967 - joshua-zivkovic:joshua-zivkovic/disable-split-debuginfo, r=jieyouxu
Disable run-make/split-debuginfo test for RISC-V 64

Together with `@Hoverbear,` we've been improving the state of the riscv64gc-unknown-linux-gnu target.

This is in relation to https://github.com/rust-lang/rust/pull/125220 where `tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs` was disabled for RISC-V 64 in that another test, `tests/run-make/split-debuginfo` also needs to be disabled due to https://github.com/llvm/llvm-project/issues/56642 and the changes made in https://github.com/rust-lang/rust/pull/120518.

This test appears to be a host test, not a target test, so it isn't seen failing in https://github.com/rust-lang/rust/pull/126641, however, we are in the process of testing host tools for riscv64-gc-unknown-linux-gnu so this test has now been noticed to be a problem.
2024-07-19 17:06:52 +02:00
Matthias Krüger
9f8c618a90
Rollup merge of #127856 - RalfJung:interpret-cast-sanity, r=oli-obk
interpret: add sanity check in dyn upcast to double-check what codegen does

For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.)

This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path.

r? ``@oli-obk``
2024-07-19 17:06:50 +02:00
León Orell Valerian Liehr
633f41de09
Update all rustdoc-json/ tests to use the new style 2024-07-19 16:54:42 +02:00
Huang Qi
a84ddc80ac Add NuttX based targets for RISC-V and ARM
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. It is scalable from 8-bit to 64-bit microcontroller environments. The primary governing standards in NuttX are POSIX and ANSI standards.

NuttX adopts additional standard APIs from Unix and other common RTOSs, such as VxWorks. These APIs are used for functionality not available under the POSIX and ANSI standards. However, some APIs, like fork(), are not appropriate for deeply-embedded environments and are not implemented in NuttX.

For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.

I'll be adding libstd support for NuttX in the future, but for now I'll just add the targets.

Tier 3 policy:

> A tier 3 target must have a designated developer or developers (the "target
>  maintainers") on record to be CCed when issues arise regarding the target.
>  (The mechanism to track and CC such developers may evolve over time.)

I will be the target maintainer for this target on matters that pertain to the NuttX part of the triple.
For matters pertaining to the riscv or arm part of the triple, there should be no difference from all other targets. If there are issues, I will address issues regarding the target.

> Targets must use naming consistent with any existing targets; for instance, a
> target for the same CPU or OS as an existing Rust target should use the same
> name for that CPU or OS. Targets should normally use the same names and
> naming conventions as used elsewhere in the broader ecosystem beyond Rust
> (such as in other toolchains), unless they have a very good reason to
> diverge. Changing the name of a target can be highly disruptive, especially
> once the target reaches a higher tier, so getting the name right is important
> even for a tier 3 target.

This is a new supported OS, so I have taken the origin target like `riscv32imac-unknown-none-elf` or `thumbv7m-none-eabi`
and changed the `os` section to `nuttx`.

> Target names should not introduce undue confusion or ambiguity unless
> absolutely necessary to maintain ecosystem compatibility. For example, if
> the name of the target makes people extremely likely to form incorrect
> beliefs about what it targets, the name should be changed or augmented to
> disambiguate it.

I feel that the target name does not introduce any ambiguity.

> Tier 3 targets may have unusual requirements to build or use, but must not
> create legal issues or impose onerous legal terms for the Rust project or for
> Rust developers or users.

The only unusual requirement for building the compiler-builtins crate is a standard RISC-V or ARM C compiler supported by cc-rs, and using this target does not require any additional software beyond what is shipped by rustup.

> The target must not introduce license incompatibilities.

All of the additional code will use Apache-2.0.

> Anything added to the Rust repository must be under the standard Rust
> license (`MIT OR Apache-2.0`).

Agreed, and there is no problem here.

> The target must not cause the Rust tools or libraries built for any other
> host (even when supporting cross-compilation to the target) to depend
> on any new dependency less permissive than the Rust licensing policy. This
> applies whether the dependency is a Rust crate that would require adding
> new license exceptions (as specified by the `tidy` tool in the
> rust-lang/rust repository), or whether the dependency is a native library
> or binary. In other words, the introduction of the target must not cause a
> user installing or running a version of Rust or the Rust tools to be
> subject to any new license requirements.

No new dependencies are added.

> Compiling, linking, and emitting functional binaries, libraries, or other
> code for the target (whether hosted on the target itself or cross-compiling
> from another target) must not depend on proprietary (non-FOSS) libraries.
> Host tools built for the target itself may depend on the ordinary runtime
> libraries supplied by the platform and commonly used by other applications
> built for the target, but those libraries must not be required for code
> generation for the target; cross-compilation to the target must not require
> such libraries at all. For instance, `rustc` built for the target may
> depend on a common proprietary C runtime library or console output library,
> but must not depend on a proprietary code generation library or code
> optimization library. Rust's license permits such combinations, but the
> Rust project has no interest in maintaining such combinations within the
> scope of Rust itself, even at tier 3.

Linking is performed by rust-lld

> "onerous" here is an intentionally subjective term. At a minimum, "onerous"
> legal/licensing terms include but are *not* limited to: non-disclosure
> requirements, non-compete requirements, contributor license agreements
> (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
> requirements conditional on the employer or employment of any particular
> Rust developers, revocable terms, any requirements that create liability
> for the Rust project or its developers or users, or any requirements that
> adversely affect the livelihood or prospects of the Rust project or its
> developers or users.

There are no terms. NuttX is distributed under the Apache 2.0 license.

> Neither this policy nor any decisions made regarding targets shall create any
> binding agreement or estoppel by any party. If any member of an approving
> Rust team serves as one of the maintainers of a target, or has any legal or
> employment requirement (explicit or implicit) that might affect their
> decisions regarding a target, they must recuse themselves from any approval
> decisions regarding the target's tier status, though they may otherwise
> participate in discussions.

I'm not the reviewer here.

> This requirement does not prevent part or all of this policy from being
> cited in an explicit contract or work agreement (e.g. to implement or
> maintain support for a target). This requirement exists to ensure that a
> developer or team responsible for reviewing and approving a target does not
> face any legal threats or obligations that would prevent them from freely
> exercising their judgment in such approval, even if such judgment involves
> subjective matters or goes beyond the letter of these requirements.

Again I'm not the reviewer here.

> Tier 3 targets should attempt to implement as much of the standard libraries
> as possible and appropriate (`core` for most targets, `alloc` for targets
> that can support dynamic memory allocation, `std` for targets with an
> operating system or equivalent layer of system-provided functionality), but
> may leave some code unimplemented (either unavailable or stubbed out as
> appropriate), whether because the target makes it impossible to implement or
> challenging to implement. The authors of pull requests are not obligated to
> avoid calling any portions of the standard library on the basis of a tier 3
> target not implementing those portions.
> The target must provide documentation for the Rust community explaining how
> to build for the target, using cross-compilation if possible. If the target
> supports running binaries, or running tests (even if they do not pass), the
> documentation must explain how to run such binaries or tests for the target,
> using emulation if possible or dedicated hardware if necessary.

Building is described in platform support doc, but libstd is not supported now,
I'll implement it later.

> Tier 3 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to maintain the target. In particular,
> do not post comments (automated or manual) on a PR that derail or suggest a
> block on the PR based on a tier 3 target. Do not send automated messages or
> notifications (via any medium, including via `@`) to a PR author or others
> involved with a PR regarding a tier 3 target, unless they have opted into
> such messages.

Understood.

> Backlinks such as those generated by the issue/PR tracker when linking to
> an issue or PR are not considered a violation of this policy, within
> reason. However, such messages (even on a separate repository) must not
> generate notifications to anyone involved with a PR who has not requested
> such notifications.

Understood.

> Patches adding or updating tier 3 targets must not break any existing tier 2
> or tier 1 target, and must not knowingly break another tier 3 target without
> approval of either the compiler team or the maintainers of the other tier 3
> target.

I believe I didn't break any other target.

> In particular, this may come up when working on closely related targets,
> such as variations of the same architecture with different features. Avoid
> introducing unconditional uses of features that another variation of the
> target may not have; use conditional compilation or runtime detection, as
> appropriate, to let each target run code supported by that target.

I think there are no such problems in this PR.

> Tier 3 targets must be able to produce assembly using at least one of
> rustc's supported backends from any host target. (Having support in a fork
> of the backend is not sufficient, it must be upstream.)

Yes, it use standard RISCV or ARM backend to generate assembly.

Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
2024-07-19 22:00:42 +08:00
bors
3811f40d27 Auto merge of #127957 - matthiaskrgr:rollup-1u5ivck, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #127350 (Parser: Suggest Placing the Return Type After Function Parameters)
 - #127621 (Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake)
 - #127662 (When finding item gated behind a `cfg` flag, point at it)
 - #127903 (`force_collect` improvements)
 - #127932 (rustdoc: fix `current` class on sidebar modnav)
 - #127943 (Don't allow unsafe statics outside of extern blocks)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 13:39:12 +00:00
Joshua Zivkovic
6edf0fc767
Disable run-make/split-debuginfo test for RISC-V 64
Due to https://github.com/rust-lang/rust/pull/120518
2024-07-19 14:32:32 +01:00
bors
11e57241f1 Auto merge of #127956 - tgross35:rollup-8ten7pk, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #121533 (Handle .init_array link_section specially on wasm)
 - #127825 (Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake)
 - #127891 (Tweak suggestions when using incorrect type of enum literal)
 - #127902 (`collect_tokens_trailing_token` cleanups)
 - #127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake)
 - #127935 (Change `binary_asm_labels` to only fire on x86 and x86_64)
 - #127953 ([compiletest] Search *.a when getting dynamic libraries on AIX)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 11:08:02 +00:00
Matthias Krüger
6fe68f88e7
Rollup merge of #127943 - compiler-errors:no-unsafe, r=spastorino
Don't allow unsafe statics outside of extern blocks

This PR fixes a regression where we allowed `unsafe static` items in top-level modules (i.e. outside of `unsafe extern` blocks).

It's harder IMO to integrate this into the `check_item_safety` function, so I opted to just put this check on the `static` item itself.

Beta version of this lives at #127944.

r? ```@oli-obk``` or ```@spastorino```
2024-07-19 10:48:06 +02:00
Matthias Krüger
1c665738de
Rollup merge of #127932 - notriddle:notriddle/current, r=GuillaumeGomez
rustdoc: fix `current` class on sidebar modnav

| Before | After |
| -- | -- |
| ![image](https://github.com/user-attachments/assets/35866be8-5a58-41eb-9169-b2bb403fe7cd) | ![image](https://github.com/user-attachments/assets/89b087ea-82bf-49f5-9c87-20162880eb32)
2024-07-19 10:48:06 +02:00
Matthias Krüger
98fdfcb11b
Rollup merge of #127662 - estebank:gate-span, r=TaKO8Ki
When finding item gated behind a `cfg` flag, point at it

Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules.

```
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
  --> $DIR/diagnostics-cross-crate.rs:18:23
   |
LL |     cfged_out::inner::doesnt_exist::hello();
   |                       ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
   |
note: found an item that was configured out
  --> $DIR/auxiliary/cfged_out.rs:6:13
   |
LL |     pub mod doesnt_exist {
   |             ^^^^^^^^^^^^
note: the item is gated here
  --> $DIR/auxiliary/cfged_out.rs:5:5
   |
LL |     #[cfg(FALSE)]
   |     ^^^^^^^^^^^^^
```
2024-07-19 10:48:05 +02:00
Matthias Krüger
7161e2dc98
Rollup merge of #127621 - Oneirical:hypnotest-show, r=jieyouxu
Rewrite and rename `issue-22131` and `issue-26006` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: x86_64-msvc
try-job: i686-mingw
2024-07-19 10:48:04 +02:00
Matthias Krüger
c86e13f330
Rollup merge of #127350 - veera-sivarajan:bugfix-126311, r=lcnr
Parser: Suggest Placing the Return Type After Function Parameters

Fixes #126311

This PR suggests placing the return type after the function parameters when it's misplaced after a `where` clause.

This also tangentially improves diagnostics for cases like [this](86d6f1312a/tests/ui/parser/issues/misplaced-return-type-without-where-issue-126311.rs (L1C1-L1C28)) and adds doc comments for `parser::AllowPlus`.
2024-07-19 10:48:03 +02:00
bors
8c3a94a1c7 Auto merge of #125915 - camelid:const-arg-refactor, r=BoxyUwU
Represent type-level consts with new-and-improved `hir::ConstArg`

### Summary

This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:

- Add `current_def_id_parent` to `LoweringContext`

  This is needed to track anon const parents properly once we implement
  `ConstArgKind::Path` (which requires moving anon const def-creation
  outside of `DefCollector`).

- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
  existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.

- Use `ConstArg` for all instances of const args. Specifically, use it instead
  of `AnonConst` for assoc item constraints, array lengths, and const param
  defaults.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.

### Followup items post-merge

- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
  instead (do this in rustc_resolve). Then remove the special-casing from
  `rustc_ast_lowering`, so that all params will automatically be lowered as
  `ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
  trying it in crater

r? `@BoxyUwU`
2024-07-19 08:44:51 +00:00
Trevor Gross
6bdf9bd276
Rollup merge of #127935 - tgross35:binary_asm_labels-x86-only, r=estebank,Urgau
Change `binary_asm_labels` to only fire on x86 and x86_64

In <https://github.com/rust-lang/rust/pull/126922>, the `binary_asm_labels` lint was added which flags labels such as `0:` and `1:`. Before that change, LLVM was giving a confusing error on x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message and have not been a problem. This means that the lint was causing code that previously worked to start failing (e.g. `compiler_builtins`), rather than only providing a more clear messages where there has always been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this regression.

Also update the help message.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-19 03:27:50 -05:00
Trevor Gross
0641b37747
Rollup merge of #127928 - Oneirical:anatesthetic-sleep, r=Kobzol
Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
2024-07-19 03:27:49 -05:00
Trevor Gross
fc6e34f38f
Rollup merge of #127891 - estebank:enum-type-sugg, r=estebank
Tweak suggestions when using incorrect type of enum literal

More accurate suggestions when writing wrong style of enum variant literal:

```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```

Tweak "field not found" suggestion when giving struct literal for tuple struct type:

```
error[E0560]: struct `S` has no field named `x`
  --> $DIR/nested-non-tuple-tuple-struct.rs:8:19
   |
LL | pub struct S(f32, f32);
   |            - `S` defined here
...
LL |     let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
   |                   ^ field does not exist
   |
help: `S` is a tuple struct, use the appropriate syntax
   |
LL |     let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
   |               ~~~~~~~~~~~~~~~~~~~~~~~
2024-07-19 03:27:48 -05:00
Trevor Gross
39ccb8a769
Rollup merge of #127825 - Oneirical:self-testeem, r=jieyouxu
Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: x86_64-msvc
try-job: aarch64-apple
2024-07-19 03:27:47 -05:00
surechen
9747a2c3ef fixes panic error
fixes #127915
2024-07-19 09:34:32 +08:00
Michael Goulet
2f5a84ea16 Don't allow unsafe statics outside of extern blocks 2024-07-18 18:02:29 -04:00
Matthias Krüger
d1250bc1d5
Rollup merge of #127929 - estebank:addr_of, r=compiler-errors
Use more accurate span for `addr_of!` suggestion

Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 23:05:24 +02:00
Matthias Krüger
65de5d0472
Rollup merge of #127871 - compiler-errors:recursive, r=estebank
Mention that type parameters are used recursively on bivariance error

Right now when a type parameter is used recursively, even with indirection (so it has a finite size) we say that the type parameter is unused:

```
struct B<T>(Box<B<T>>);
```

This is confusing, because the type parameter is *used*, it just doesn't have its variance constrained. This PR tweaks that message to mention that it must be used *non-recursively*.

Not sure if we should actually mention "variance" here, but also I'd somewhat prefer we don't keep the power users in the dark w.r.t the real underlying issue, which is that the variance isn't constrained. That technical detail is reserved for a note, though.

cc `@fee1-dead`

Fixes #118976
Fixes #26283
Fixes #53191
Fixes #105740
Fixes #110466
2024-07-18 23:05:22 +02:00
Matthias Krüger
50a90e394e
Rollup merge of #127835 - estebank:issue-127823, r=compiler-errors
Fix ICE in suggestion caused by `⩵` being recovered as `==`

The second suggestion shown here would previously incorrectly assume that the span corresponding to `⩵` was 2 bytes wide composed by 2 1 byte wide chars, so a span pointing at `==` could point only at one of the `=` to remove it. Instead, we now replace the whole thing (as we should have the whole time):

```
error: unknown start of token: \u{2a75}
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not
   |
LL | const A: usize == 2;
   |                ~~

error: unexpected `==`
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: try using `=` instead
   |
LL | const A: usize = 2;
   |                ~
```

Fix #127823.
2024-07-18 23:05:21 +02:00
Matthias Krüger
c1bbe347c2
Rollup merge of #127594 - c6c7:fuchsia-status-code-match-arm, r=tmandry
Fuchsia status code match arm

Adds a match arm for the Fuchsia status code upon a process abort. An additional change moves the Windows status code down into the match arm itself instead of being defined as a constant elsewhere.

r​? tmandry
2024-07-18 23:05:21 +02:00
Matthias Krüger
7c1bf86417
Rollup merge of #127418 - GuillaumeGomez:wrap-too-long-type-name, r=notriddle
Wrap too long type name

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

Takeover of #126209.

cc `@BradMarr`
r? `@notriddle`
2024-07-18 23:05:20 +02:00
Trevor Gross
8410348b1c Update the binary_asm_label message
The link pointed to a closed issue. Create a new one and point the link
to it.

Also add a help message to hint what change the user could make.

Fixes: https://github.com/rust-lang/rust/issues/127821
2024-07-18 17:00:43 -04:00
Michael Goulet
e0ba1931f4 Revert "sort suggestions for object diagnostic"
This reverts commit 540be28f6c.
2024-07-18 16:51:06 -04:00
Michael Goulet
d325fb7c2e Make clippy and rustdoc happy 2024-07-18 16:51:05 -04:00
Oneirical
730313227f rewrite link-path-order to rmake 2024-07-18 16:27:34 -04:00
Esteban Küber
9dffe9573b Make unicode text flow control chars visible as �
We already point these out quite aggressively, telling people not to use them, but would normally be rendered as nothing. Having them visible will make it easier for people to actually deal with them.

```
error: unicode codepoint changing visible direction of text present in literal
  --> $DIR/unicode-control-codepoints.rs:26:22
   |
LL |     println!("{:?}", '�');
   |                      ^-^
   |                      ||
   |                      |'\u{202e}'
   |                      this literal contains an invisible unicode text flow control codepoint
   |
   = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
   = help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
   |
LL |     println!("{:?}", '\u{202e}');
   |                       ~~~~~~~~
```

vs the previous

```
error: unicode codepoint changing visible direction of text present in literal
  --> $DIR/unicode-control-codepoints.rs:26:22
   |
LL |     println!("{:?}", '');
   |                      ^-
   |                      ||
   |                      |'\u{202e}'
   |                      this literal contains an invisible unicode text flow control codepoint
   |
   = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
   = help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
   |
LL |     println!("{:?}", '\u{202e}');
   |                       ~~~~~~~~
```
2024-07-18 20:08:43 +00:00
Esteban Küber
2d7795dfb9 Be more accurate about calculating display_col from a BytePos
No longer track "zero-width" chars in `SourceMap`, read directly from the line when calculating the `display_col` of a `BytePos`. Move `char_width` to `rustc_span` and use it from the emitter.

This change allows the following to properly align in terminals (depending on the font, the replaced control codepoints are rendered as 1 or 2 width, on my terminal they are rendered as 1, on VSCode text they are rendered as 2):

```
error: this file contains an unclosed delimiter
  --> $DIR/issue-68629.rs:5:17
   |
LL | ␜␟ts␀![{i
   |       -- unclosed delimiter
   |       |
   |       unclosed delimiter
LL | ␀␀  fn rݻoa>rݻm
   |                ^
```
2024-07-18 20:08:38 +00:00
Trevor Gross
9387a7523e Change binary_asm_labels to only fire on x86 and x86_64
In <https://github.com/rust-lang/rust/pull/126922>, the
`binary_asm_labels` lint was added which flags labels such as `0:` and
`1:`. Before that change, LLVM was giving a confusing error on
x86/x86_64 because of an incorrect interpretation.

However, targets other than x86 and x86_64 never had the error message
and have not been a problem. This means that the lint was causing code
that previously worked to start failing (e.g. `compiler_builtins`),
rather than only providing a more clear messages where there has always
been an error.

Adjust the lint to only fire on x86 and x86_64 assembly to avoid this
regression.
2024-07-18 15:00:56 -05:00
Esteban Küber
89f273f40d Replace ASCII control chars with Unicode Control Pictures
```
error: bare CR not allowed in doc-comment
  --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
   |
LL | /// doc comment with bare CR: '␍'
   |                                ^
```
2024-07-18 19:23:42 +00:00
Michael Howell
2e1e627430 rustdoc: fix current class on sidebar modnav 2024-07-18 12:06:21 -07:00
Guillaume Gomez
c820a2392c Add test for size of items in the items list 2024-07-18 20:48:20 +02:00
Esteban Küber
abf92c049d Use more accurate span for addr_of! suggestion
Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 18:39:20 +00:00
Esteban Küber
33bd4bdeb5 Tweak "field not found" suggestion when giving struct literal for tuple struct type
```
error[E0560]: struct `S` has no field named `x`
  --> $DIR/nested-non-tuple-tuple-struct.rs:8:19
   |
LL | pub struct S(f32, f32);
   |            - `S` defined here
...
LL |     let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
   |                   ^ field does not exist
   |
help: `S` is a tuple struct, use the appropriate syntax
   |
LL |     let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
   |               ~~~~~~~~~~~~~~~~~~~~~~~
```
2024-07-18 18:20:35 +00:00
Esteban Küber
ec7a188f16 More accurate suggestions when writing wrong style of enum variant literal
```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```
2024-07-18 18:20:35 +00:00
Esteban Küber
2259db6af0 Add svg test for incorrect literal type suggestion 2024-07-18 18:20:32 +00:00
Esteban Küber
67ec1326ee Fix ICE in suggestion caused by being recovered as ==
The second suggestion shown here would previously incorrectly assume that the span corresponding to `⩵` was 2 bytes wide composed by 2 1 byte wide chars, so a span pointing at `==` could point only at one of the `=` to remove it. Instead, we now replace the whole thing (as we should have the whole time):

```
error: unknown start of token: \u{2a75}
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not
   |
LL | const A: usize == 2;
   |                ~~

error: unexpected `==`
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: try using `=` instead
   |
LL | const A: usize = 2;
   |                ~
```
2024-07-18 17:47:31 +00:00
Oneirical
741cf91678 rewrite lto-smoke-c to rmake 2024-07-18 13:42:15 -04:00
Matthias Krüger
4ad2c99b6d
Rollup merge of #127854 - fmease:glob-import-type_ir_inherent-lint, r=compiler-errors
Add internal lint for detecting non-glob imports of `rustc_type_ir::inherent`

https://github.com/rust-lang/rust/pull/127627#issuecomment-2225295951

r? compiler-errors
2024-07-18 18:10:16 +02:00
Matthias Krüger
6f7fa03a06
Rollup merge of #127748 - scottmcm:option_len, r=joboet
Use Option's discriminant as its size hint

I was looking at this in MIR after a question on discord, and noticed that it ends up with a switch in MIR (<https://rust.godbolt.org/z/3q4cYnnb3>), which it doesn't need because (as `Option::as_slice` uses) the discriminant is already the length.
2024-07-18 18:10:16 +02:00
Matthias Krüger
ec6110f00c
Rollup merge of #127656 - RalfJung:pub_use_of_private_extern_crate, r=petrochenkov
make pub_use_of_private_extern_crate show up in cargo's future breakage reports

This has been a lint for many years.

However, turns out that outright removing it right now would lead to [tons of crater regressions](https://github.com/rust-lang/rust/pull/127656#issuecomment-2233288534) due to crates depending on an ancient version of `bitflags`. So for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.

r? `@petrochenkov`
2024-07-18 18:10:15 +02:00
Oneirical
fc4404c230 Rewrite and rename issue-26006 to rmake 2024-07-18 11:14:07 -04:00
Oneirical
9dc08e30bd Rewrite and rename issue-22131 to rmake 2024-07-18 11:13:59 -04:00
Oneirical
f1747f40a3 rewrite rlib-format-packed-bundled-libs-3 to rmake 2024-07-18 09:34:56 -04:00
Oneirical
7d3cbb3e93 rewrite staticlib-blank-lib to rmake 2024-07-18 09:34:54 -04:00
bors
5753b30676 Auto merge of #117967 - adetaylor:fix-lifetime-elision-bug, r=lcnr
Fix ambiguous cases of multiple & in elided self lifetimes

This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime.

## The old rules

(copied from [this comment](https://github.com/rust-lang/rust/pull/117967#discussion_r1420554242))

Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types.

Here's how:
* If the first parameter is called self then we search that parameter using "`self` search rules", below
* If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below

(In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.)

### `self` search rules

This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](https://github.com/rust-lang/rust/issues/117715#issuecomment-1813115477) already. The code:

1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see)
2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes
3. If there's exactly one such unique lifetime candidate found, we return this lifetime.

### Regular parameter search rules

1. Find all the lifetimes in each parameter, including implicit, explicit etc.
2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime.

## The new rules

There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now:

1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1]
2. Keep a record of:
   * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk
4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision).
5. If there's one lifetime found, we return the lifetime.
6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used).

[^1]: this prevents us from considering lifetimes from inside of the self-type

## Examples that were accepted before and will now be rejected

```rust
fn a(self: &Box<&Self>) -> &u32
fn b(self: &Pin<&mut Self>) -> &String
fn c(self: &mut &Self) -> Option<&Self>
fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg
```

### Examples that change the elided lifetime

```rust
fn e(self: &mut Box<Self>, arg: &usize) -> &usize
//         ^ new                ^ previous
```

## Examples that were rejected before and will now be accepted

```rust
fn f(self: &Box<Self>) -> &u32
```

---

*edit: old PR description:*

```rust
  struct Concrete(u32);

  impl Concrete {
      fn m(self: &Box<Self>) -> &u32 {
          &self.0
      }
  }
```

resulted in a confusing error.

```rust
  impl Concrete {
      fn n(self: &Box<&Self>) -> &u32 {
          &self.0
      }
  }
```

resulted in no error or warning, despite apparent ambiguity over the elided lifetime.

Fixes https://github.com/rust-lang/rust/issues/117715
2024-07-18 13:33:38 +00:00
Oneirical
47c21012ef rewrite archive-duplicate-names to rmake 2024-07-18 09:28:50 -04:00
Oneirical
aeca91e08d rewrite manual-link to rmake 2024-07-18 09:28:30 -04:00
Oneirical
06dcdbb2ee rewrite macos-fat-archive to rmake 2024-07-18 09:28:30 -04:00
Folkert
c2894a4297
improve error reporting 2024-07-18 14:32:10 +02:00
Guillaume Gomez
26d72512e0 Unify UI between code block buttons and top buttons 2024-07-18 14:16:29 +02:00
Guillaume Gomez
578810b4d2 Make "copy code" button the same size as the "copy path" button 2024-07-18 14:16:29 +02:00
Guillaume Gomez
ddaa90fc56 Add rustdoc GUI test for new copy code feature 2024-07-18 14:16:29 +02:00
Ralf Jung
0871175a4d make pub_use_of_private_extern_crate show up in future breakage reports 2024-07-18 13:43:56 +02:00
León Orell Valerian Liehr
2507301de0
Add internal lint for detecting non-glob imports of rustc_type_ir::inherent 2024-07-18 13:03:26 +02:00
Folkert
7b63734961
move CMSE validation to hir_analysis 2024-07-18 12:42:40 +02:00
Trevor Gross
d817c0f87a
Rollup merge of #127822 - Oneirical:amazon-rainfortest, r=jieyouxu
Migrate `issue-85401-static-mir`, `missing-crate-dependency` and `unstable-flag-required` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: dist-x86_64-linux
2024-07-18 05:14:06 -05:00
Trevor Gross
a2178dffc8
Rollup merge of #127687 - RalfJung:pattern-cleanup, r=oli-obk,lcnr
Const-to-pattern-to-MIR cleanup

Now that all uses of constants without structural equality are hard errors, there's a bunch of cleanup we can do in the code that handles patterns: we can always funnel patterns through valtrees first (rather than having a fallback path for when valtree construction fails), and we can make sure that if we emit a `PartialEq` call it is not calling anything user-defined.

To keep the error messages the same, I made valtree construction failures return the information of *which* type it is that cannot be valtree'd. `search_for_structural_match_violation` is now not needed any more at all, so I removed it.

r? `@oli-obk`
2024-07-18 05:14:05 -05:00
Trevor Gross
78fe5f76bf
Rollup merge of #127491 - Oneirical:bulletproof-test, r=jieyouxu
Migrate 8 very similar FFI `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

There are some more of these, but while the code is almost always the same, I want to keep the number reasonable so my doc comments can be inspected for potential inaccuracies. Tell me if 8 is too much, I can cut this down.

For the tracking issue:

- issue-25581
- extern-fn-with-extern-types
- extern-fn-struct-passing-abi
- longjmp-across-rust
- static-extern-type
- extern-fn-explicit-align
- extern-fn-with-packed-struct
- extern-fn-mangle
2024-07-18 05:14:04 -05:00
Ralf Jung
67c99d6338 avoid creating an Instance only to immediately disassemble it again 2024-07-18 11:58:16 +02:00
Ralf Jung
e613bc92a1 const_to_pat: cleanup leftovers from when we had to deal with non-structural constants 2024-07-18 11:58:16 +02:00
Ralf Jung
a7b80819e9 interpret: add sanity check in dyn upcast to double-check what codegen does 2024-07-18 11:41:10 +02:00
Matthias Krüger
77e5bbf341
Rollup merge of #127889 - estebank:anon-arg-sugg, r=compiler-errors
More accurate span for anonymous argument suggestion

Use smaller span for suggesting adding `_:` ahead of a type:

```
error: expected one of `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
  --> $DIR/anon-params-denied-2018.rs:12:47
   |
LL |     fn foo_with_qualified_path(<Bar as T>::Baz);
   |                                               ^ expected one of 8 possible tokens
   |
   = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
   |
LL |     fn foo_with_qualified_path(_: <Bar as T>::Baz);
   |                                ++
```
2024-07-18 08:09:02 +02:00
Matthias Krüger
d78be31a2a
Rollup merge of #127888 - estebank:type-param-sugg, r=compiler-errors
More accurate span for type parameter suggestion

After:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
   |
```

Before:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL | impl<T: Default> Foo<T> for String {}
   |     ++++++++++++     ~
```
2024-07-18 08:09:02 +02:00
Matthias Krüger
b52883decf
Rollup merge of #127886 - estebank:as-rename-suggestion, r=compiler-errors
Accurate `use` rename suggestion span

When suggesting to rename an import with `as`, use a smaller span to render the suggestion with a better format:

```
error[E0252]: the name `baz` is defined multiple times
  --> $DIR/issue-25396.rs:4:5
   |
LL | use foo::baz;
   |     -------- previous import of the module `baz` here
LL | use bar::baz;
   |     ^^^^^^^^ `baz` reimported here
   |
   = note: `baz` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
LL | use bar::baz as other_baz;
   |              ++++++++++++
```
2024-07-18 08:09:01 +02:00
Matthias Krüger
a13d7dbecf
Rollup merge of #127878 - estebank:assoc-item-removal, r=fmease
Fix associated item removal suggestion

We were previously telling people to write what was already there, instead of removal (treating it as a `help`). We now properly suggest to remove the code that needs to be removed.

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/E0229.rs:13:25
   |
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
   |                         ^^^^^^^ associated item constraint not allowed here
   |
help: consider removing this associated item binding
   |
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
   |
```
2024-07-18 08:09:01 +02:00
Matthias Krüger
2013bf9077
Rollup merge of #127787 - Rejyr:migrate-atomic-lock-free-rmake, r=jieyouxu
Migrate `atomic-lock-free` to `rmake`

Also adds `llvm_components_contain` to `run-make-support`.

Part of #121876.

r? ``@jieyouxu``

try-job: dist-x86_64-linux
2024-07-18 08:08:59 +02:00
Matthias Krüger
97d5edf4b1
Rollup merge of #127783 - compiler-errors:rtn-pretty, r=fee1-dead
Put the dots back in RTN pretty printing

Also don't render RTN-like bounds for methods with ty/const params.
2024-07-18 08:08:59 +02:00
Michael Goulet
c02d0de871 Account for structs that have unused params in nested types in fields 2024-07-17 21:12:12 -04:00
Trevor Gross
b5771e7e0d
Rollup merge of #127664 - compiler-errors:precise-capturing-better-sugg-apit, r=oli-obk
Fix precise capturing suggestion for hidden regions when we have APITs

Suggests to turn APITs into type parameters so they can be named in precise capturing syntax for hidden type lifetime errors. We also note that it may change the API.

This is currently done via a note *and* a suggestion, which feels a bit redundant, but I wasn't totally sure of a better alternative for the presentation.

Code is kind of a mess but there's a lot of cases to consider. Happy to iterate on this if you think the approach is too messy.

Based on #127619, only the last commit is relevant.
r? oli-obk

Tracking:

- https://github.com/rust-lang/rust/issues/123432
2024-07-17 19:53:26 -05:00
Trevor Gross
e6f0caf197
Rollup merge of #127542 - c410-f3r:concat-again, r=petrochenkov
[`macro_metavar_expr_concat`] Add support for literals

Adds support for literals in macro parameters.

```rust
macro_rules! with_literal {
    ($literal:literal) => {
        const ${concat(FOO, $literal)}: i32 = 1;
    }
}

fn main() {
    with_literal!("_BAR");
    assert_eq!(FOO_BAR, 1);
}
```

cc #124225

r? ``@petrochenkov``
2024-07-17 19:53:25 -05:00
Esteban Küber
f6c4679547 More accurate span for anonymous argument suggestion
Use smaller span for suggesting adding `_:` ahead of a type:

```
error: expected one of `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
  --> $DIR/anon-params-denied-2018.rs:12:47
   |
LL |     fn foo_with_qualified_path(<Bar as T>::Baz);
   |                                               ^ expected one of 8 possible tokens
   |
   = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
   |
LL |     fn foo_with_qualified_path(_: <Bar as T>::Baz);
   |                                ++
```
2024-07-18 00:19:27 +00:00
Esteban Küber
be9d961884 More accurate span for type parameter suggestion
After:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
   |
```

Before:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL | impl<T: Default> Foo<T> for String {}
   |     ++++++++++++     ~
```
2024-07-18 00:10:48 +00:00
Esteban Küber
8eb51852a8 Accurate use rename suggestion span
When suggesting to rename an import with `as`, use a smaller span to
render the suggestion with a better format:

```
error[E0252]: the name `baz` is defined multiple times
  --> $DIR/issue-25396.rs:4:5
   |
LL | use foo::baz;
   |     -------- previous import of the module `baz` here
LL | use bar::baz;
   |     ^^^^^^^^ `baz` reimported here
   |
   = note: `baz` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
LL | use bar::baz as other_baz;
   |              ++++++++++++
```
2024-07-18 00:00:04 +00:00
Michael Goulet
29f5d8f00f Don't elaborate associated types with Sized bounds in trait_object_ty in cfi 2024-07-17 18:26:21 -04:00
bors
e35364a521 Auto merge of #127865 - matthiaskrgr:rollup-8m49dlg, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #125042 (Use ordinal number in argument error)
 - #127229 (rustdoc: click target for sidebar items flush left)
 - #127337 (Move a few intrinsics to Rust abi)
 - #127472 (MIR building: Stop using `unpack!` for `BlockAnd<()>`)
 - #127579 (Solve a error `.clone()` suggestion when moving a mutable reference)
 - #127769 (Don't use implicit features in `Cargo.toml` in `compiler/`)
 - #127844 (Remove invalid further restricting suggestion for type bound)
 - #127855 (Add myself to review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-17 21:52:29 +00:00
Matthew Maurer
2abdc4e98c CFI: Support provided methods on traits
Provided methods currently don't get type erasure performed on them
because they are not in an `impl` block. If we are instantiating a
method that is an associated item, but *not* in an impl block, treat it
as a provided method instead.
2024-07-17 21:45:43 +00:00
Esteban Küber
e38032fb3a Fix associated item removal suggestion
We were previously telling people to write what was already there, instead of removal.

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/E0229.rs:13:25
   |
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
   |                         ^^^^^^^ associated item constraint not allowed here
   |
help: consider removing this associated item binding
   |
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
   |
```
2024-07-17 21:30:40 +00:00
Michael Goulet
a0a251a688 Account for self ty alias 2024-07-17 16:48:17 -04:00
Jerry Wang
a8b6e3f5c9
Migrate atomic-lock-free to rmake 2024-07-17 16:47:39 -04:00
Oneirical
3ba62f0a63 rewrite unstable-flag-required to rmake 2024-07-17 16:11:11 -04:00
Oneirical
890ef1180b rewrite missing-crate-dependency to rmake 2024-07-17 16:10:44 -04:00
Oneirical
d83ada35ed rewrite and rename issue-85401-static-mir 2024-07-17 16:10:22 -04:00
Caio
553279b152 Add support for literals 2024-07-17 17:00:48 -03:00
Michael Goulet
3716a3fd31 Mention that type parameters are used recursively 2024-07-17 15:57:38 -04:00
Oneirical
c68d25b097 rewrite extern-fn-mangle to rmake 2024-07-17 15:33:17 -04:00
Oneirical
f7d67d6b68 rewrite extern-fn-with-packed-struct to rmake 2024-07-17 15:33:07 -04:00
Oneirical
bde91785dc rewrite extern-fn-explicit-align to rmake 2024-07-17 15:33:07 -04:00
Oneirical
205bfe7213 rewrite static-extern-type to rmake 2024-07-17 15:33:07 -04:00
Oneirical
98454ece33 rewrite longjmp-across-rust to rmake 2024-07-17 15:33:07 -04:00
Oneirical
d6a3f65db0 rewrite extern-fn-struct-passing-abi to rmake 2024-07-17 15:33:07 -04:00
Oneirical
a795d8998d rewrite and rename issue-25581 2024-07-17 15:33:06 -04:00
Oneirical
a47ca19134 rewrite extern-fn-with-extern-types to rmake 2024-07-17 15:33:05 -04:00
Folkert
8a3dd7fb5f
add test for unions and repr(transparent) with ZST fields 2024-07-17 21:21:33 +02:00
Michael Goulet
b84e2b7c98 Put the dots back 2024-07-17 11:08:28 -04:00
Michael Goulet
da2054f389 Add cross-crate precise capturing support to rustdoc 2024-07-17 11:06:10 -04:00
Michael Goulet
1d40d4c4f4 Fix precise capturing suggestion for hidden type when APITs are involved 2024-07-17 10:52:13 -04:00
Matthias Krüger
1e1e64f10f
Rollup merge of #127844 - chenyukang:yukang-fix-type-bound-127555, r=jieyouxu
Remove invalid further restricting suggestion for type bound

This PR partially addresses #127555, it will remove the obvious error suggestion:

```console
   |                      ^^^^ required by this bound in `<Baz as Foo>::bar`
help: consider further restricting this bound
   |
12 |         F: FnMut() + Send + std::marker::Send,
   |                           +++++++++++++++++++
```

I may create another PR to get a better diagnostic for `impl has stricter requirements than trait` scenario.
2024-07-17 16:22:32 +02:00
Matthias Krüger
23dd3a099c
Rollup merge of #127579 - surechen:fix_127285, r=lcnr
Solve a error `.clone()` suggestion when moving a mutable reference

If the moved value is a mut reference, it is used in a generic function and it's type is a generic param, suggest it can be reborrowed to avoid moving.

for example:

```rust
struct Y(u32);
// x's type is '& mut Y' and it is used in `fn generic<T>(x: T) {}`.
fn generic<T>(x: T) {}
```

fixes #127285
2024-07-17 16:22:29 +02:00
Matthias Krüger
3ddfd97198
Rollup merge of #127337 - celinval:intrinsics-fallback, r=oli-obk
Move a few intrinsics to Rust abi

Move a few more intrinsic functions to the convention added in #121192. In the second commit, I added documentation about their safety requirements. Let me know if you would like me to move the second commit to a different PR.

Note: I kept the same signature of `pref_align_of`, but I was wondering why this function is considered unsafe?
2024-07-17 16:22:28 +02:00
Matthias Krüger
0472b2a09f
Rollup merge of #127229 - notriddle:notriddle/mile-wide-bar, r=GuillaumeGomez
rustdoc: click target for sidebar items flush left

This change adjusts the clickable area of sidebar links to touch the leftmost edge of the canvas, making them [much easier](https://www.nngroup.com/articles/fitts-law/) to click (when the browser window is maximized or tiled left, but those cases are common enough to matter).

[Screencast from 2024-07-15 15-31-07.webm](https://github.com/user-attachments/assets/1e952d3a-e9e7-476b-b211-44a17c190b38)

<details><summary>old screencast</summary>

[Screencast from 2024-07-01 17-23-34.webm](https://github.com/rust-lang/rust/assets/1593513/dc6f9c2e-5904-403d-b353-d233e6e1afbc)

</details>
2024-07-17 16:22:26 +02:00
Matthias Krüger
2b34490da6
Rollup merge of #125042 - long-long-float:suggest-move-arg-outside, r=fmease
Use ordinal number in argument error

Add an ordinal number to two argument errors ("unexpected" and "missing") for ease of understanding error.

```
error[E0061]: this function takes 3 arguments but 2 arguments were supplied
  --> test.rs:11:5
   |
11 |     f(42, 'a');
   |     ^     --- 2nd argument of type `f32` is missing
   |
(snip)

error[E0061]: this function takes 3 arguments but 4 arguments were supplied
  --> test.rs:12:5
   |
12 |     f(42, 42, 1.0, 'a');
   |     ^   ----
   |         | |
   |         | unexpected 2nd argument of type `{integer}`
   |         help: remove the extra argument
```

To get an ordinal number, I copied `ordinalize` from other crate `rustc_resolve` because I think it is too much to link `rustc_resolve` for this small function. Please let me know if there is a better way.
2024-07-17 16:22:26 +02:00
Folkert
5f0f690bd6
add test for repr(transparent) enum 2024-07-17 15:41:16 +02:00
许杰友 Jieyou Xu (Joe)
d69cc1ccbf tests: update for rfs rename 2024-07-17 13:34:18 +00:00
许杰友 Jieyou Xu (Joe)
a00b860bfc tests: update rustdoc test for renamed assert_dirs_are_equal 2024-07-17 13:32:29 +00:00
许杰友 Jieyou Xu (Joe)
636be91cc0 tests: update for renamed fs module in run_make_support 2024-07-17 13:32:29 +00:00
许杰友 Jieyou Xu (Joe)
56cbfa8749 tests: update rustdoc test for renamed assert_recursive_eq 2024-07-17 12:48:22 +00:00
Tobias Bucher
bf96c56e84 Rename deprecated_safe lint to deprecated_safe_2024
Create a lint group `deprecated_safe` that includes
`deprecated_safe_2024`.

Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.
2024-07-17 14:39:56 +02:00
yukang
40e07a3ab1 Remove invalid further restricting for type bound 2024-07-17 19:08:37 +08:00
Jerry Wang
eea6502dcb
Use llvm-readobj for run-make/crate-hash-rustc-version 2024-07-17 06:49:23 -04:00
Jerry Wang
ec6e07b09d
Migrate crate-hash-rustc-version to rmake 2024-07-17 06:49:23 -04:00
Boxy
d0c11bf6e3 Split part of adt_const_params into unsized_const_params 2024-07-17 11:01:29 +01:00
bors
a28b35eb35 Auto merge of #127840 - tgross35:rollup-jfkg1dq, r=tgross35
Rollup of 9 pull requests

Successful merges:

 - #125206 (Simplify environment variable examples)
 - #126271 (Skip fast path for dec2flt when optimize_for_size)
 - #126776 (Clean up more comments near use declarations)
 - #127444 (`impl Send + Sync` and override `count` for the `CStr::bytes` iterator)
 - #127512 (Terminate `--print link-args` output with newline)
 - #127792 (std: Use `read_unaligned` for reads from DWARF)
 - #127807 (Use futex.rs for Windows thread parking)
 - #127833 (zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`)
 - #127836 (std: Forbid unwrapped unsafe ops in xous and uefi modules)

Failed merges:

 - #127813 (Prevent double reference in generic futex)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-17 03:31:18 +00:00
Noah Lev
37ed7a4438 Add ConstArgKind::Path and make ConstArg its own HIR node
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:

- `ConstArgKind` gets a new `Path` variant, and all const params are now
  represented using it. Non-param paths still use `ConstArgKind::Anon`
  to prevent this change from getting too large, but they will soon use
  the `Path` variant too.

- `ConstArg` gets a distinct `hir_id` field and its own variant in
  `hir::Node`. This affected many parts of the compiler that expected
  the parent of an `AnonConst` to be the containing context (e.g., an
  array repeat expression). They have been changed to check the
  "grandparent" where necessary.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at #127009.
2024-07-16 19:27:28 -07:00
surechen
4821b84b92 If the moved value is a mut reference, it is used in a generic function and it's type is a generic param, it can be reborrowed to avoid moving.
for example:

```rust
struct Y(u32);
// x's type is '& mut Y' and it is used in `fn generic<T>(x: T) {}`.
fn generic<T>(x: T) {}
```

fixes #127285
2024-07-17 10:07:02 +08:00
Trevor Gross
8840d302e5
Rollup merge of #127512 - eggyal:newline-terminate-print-linkargs, r=compiler-errors
Terminate `--print link-args` output with newline

Fixes #127507
2024-07-16 20:10:11 -05:00
bors
1a6e777c3c Auto merge of #126208 - Oneirical:one-flew-over-the-cuckoo's-test, r=jieyouxu
Migrate `compiler-lookup-paths`, `dump-mono-stats` and `prune-link-args` `run-make` tests to `rmake` or `ui` format

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

try-job: x86_64-msvc
try-job: aarch64-apple
try-job: dist-x86_64-linux
try-job: armhf-gnu
2024-07-17 01:09:18 +00:00
liushuyu
c940d52cb0 rustc_target: fix UI tests for s390x 2024-07-17 07:55:22 +08:00
Folkert
4d082b77af
add error message when #[naked] is used with #[test] 2024-07-17 00:04:00 +02:00
bors
7d356ebde3 Auto merge of #127831 - tgross35:rollup-c0j9n7b, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #124033 (Sync ar_archive_writer to LLVM 18.1.3)
 - #126699 (Delegation: support coercion for target expression)
 - #126762 (Deny keyword lifetimes pre-expansion)
 - #126967 (Promote the `wasm32-wasip2` target to Tier 2)
 - #127390 (Migrate `raw-dylib-inline-cross-dylib` and `raw-dylib-custom-dlltool` `run-make` tests to rmake)
 - #127501 (Invert infer `error_reporting` mod struture)
 - #127816 (Update method name to reflect changes to its internals)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-16 21:46:24 +00:00
Folkert
7e6c083873
improve error message when #[naked] is used with #[track-caller] and #[target-feature]`` 2024-07-16 23:35:02 +02:00
Trevor Gross
059222ddc9
Rollup merge of #127501 - compiler-errors:invert-infer-error-mod-struture, r=lcnr
Invert infer `error_reporting` mod struture

Parallel change to #127493, which moves `rustc_infer::infer::error_reporting` to `rustc_infer::error_reporting::infer`. After this, we should just be able to merge this into `rustc_trait_selection::error_reporting::infer`, and pull down `TypeErrCtxt` into that crate. 👍

r? lcnr
2024-07-16 16:15:16 -05:00
Trevor Gross
d18a741569
Rollup merge of #127390 - Oneirical:rough-testimation, r=jieyouxu
Migrate `raw-dylib-inline-cross-dylib` and `raw-dylib-custom-dlltool` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: i686-mingw
2024-07-16 16:15:16 -05:00
Trevor Gross
9833e21c5d
Rollup merge of #126762 - compiler-errors:kw-lt, r=michaelwoerister
Deny keyword lifetimes pre-expansion

https://github.com/rust-lang/rust/pull/126452#issuecomment-2179464266

> Secondly, we confirmed that we're OK with moving the validation of keywords in lifetimes to pre-expansion from post-expansion. We similarly consider this a bug fix. While the breakage of the convenience feature of the with_locals crate that relies on this is unfortunate, and we wish we had not overlooked this earlier for that reason, we're fortunate that the breakage is contained to only one crate, and we're going to accept this breakage as the extra complexity we'd need to carry in the compiler to work around this isn't deemed worth it.

T-lang considers it to be a bugfix to deny `'keyword` lifetimes in the parser, rather than during AST validation that only happens post-expansion. This has one breakage: https://github.com/rust-lang/rust/pull/126452#issuecomment-2171654756

This probably should get lang FCP'd just for consistency.
2024-07-16 16:15:15 -05:00
Trevor Gross
36ea06827b
Rollup merge of #126699 - Bryanskiy:delegation-coercion, r=compiler-errors
Delegation: support coercion for target expression

(solves https://github.com/rust-lang/rust/issues/118212#issuecomment-2160723092)

The implementation consist of 2 parts. Firstly, method call is generated instead of fully qualified call in AST->HIR lowering if there were no generic arguments or `Qpath` were provided. These restrictions are imposed due to the loss of information after desugaring. For example in

```rust
trait Trait {
  fn foo(&self) {}
}

reuse <u8 as Trait>::foo;
```

We would like to generate such a code:

```rust
fn foo<u8: Trait>(x: &u8) {
  x.foo(x)
}
```

however, the signature is inherited during HIR analysis where `u8` was discarded.

Then, we probe the single pre-resolved method.

P.S In the future, we would like to avoid restrictions on the callee path by `Self` autoref/autoderef in fully qualified calls, but at the moment it didn't work out.

r? `@petrochenkov`
2024-07-16 16:15:14 -05:00
Folkert
4bd36324b6
improve error message when #[naked] is used with #[inline] 2024-07-16 23:03:13 +02:00
Michael Howell
55149061ea rustdoc: add test cases for mile wide bar 2024-07-16 13:29:35 -07:00
Oneirical
ea2b699b94 build_native_static_lib with llvm_ar for run_make_support 2024-07-16 15:34:04 -04:00
Oneirical
3b495bb60b rewrite prune-link-args to rmake format 2024-07-16 15:33:26 -04:00
Oneirical
b55fa8f757 rewrite dump-mono-stats to rmake format 2024-07-16 15:33:26 -04:00
Oneirical
9ce62297fa rewrite compiler-lookup-paths to rmake 2024-07-16 15:33:26 -04:00
bors
032be6f7bb Auto merge of #126484 - Oneirical:test-in-peace, r=jieyouxu,kobzol
Migrate `std-core-cycle`, `obey-crate-type-flag`, `mixing-libs` and `issue-18943` `run-make` tests to `rmake.rs`

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

try-job: x86_64-apple-1
try-job: x86_64-msvc
try-job: aarch64-gnu
2024-07-16 19:25:51 +00:00
Michael Goulet
d0a1851ec2 Deny keyword lifetimes pre-expansion 2024-07-16 12:06:25 -04:00
Folkert
1e8606408d
add more tests for cmse-nonsecure-call stack spills 2024-07-16 17:18:33 +02:00
Bryanskiy
7ee97f93da Delegation: support coercion for target expression 2024-07-16 18:03:15 +03:00
yukang
48ddf5e323 Fix the issue of invalid suggestion for a reference of iterator 2024-07-16 22:01:55 +08:00
yukang
077d0da30a add test for issue 127590 2024-07-16 22:01:10 +08:00
Folkert
50ba821e12
add rust error message for CMSE stack spill
when the `C-cmse-nonsecure-call` ABI is used, arguments and return values must be passed via registers. Failing to do so (i.e. spilling to the stack) causes an LLVM error down the line, but now rustc will properly emit an error a bit earlier in the chain
2024-07-16 15:58:33 +02:00
Trevor Gross
1abed9fa06
Rollup merge of #127780 - compiler-errors:zip-args, r=jieyouxu
Make sure trait def ids match before zipping args in `note_function_argument_obligation`

Fixes #126416
Fixes #127745

Didn't add both tests b/c I felt like it was unnecessary.
2024-07-16 02:02:25 -05:00
Trevor Gross
12fd2f94b3
Rollup merge of #120990 - chenyukang:yukang-fix-120327-dbg, r=oli-obk
Suggest a borrow when using dbg

Fixes #120327
r? ````@estebank````
2024-07-16 02:02:23 -05:00
Michael Howell
3924493a10 rustdoc: make sidebar highlight cover whole click target 2024-07-15 17:44:05 -07:00
Michael Goulet
e86fbcfd70 Move rustc_infer::infer::error_reporting to rustc_infer::error_reporting::infer 2024-07-15 20:16:12 -04:00
bors
cae4a84146 Auto merge of #127629 - tesuji:suggest-option-ref-unwrap_or, r=estebank
Suggest using `map_or` when `Option<&T>::unwrap_or where T: Deref` fails

Fix #127545

Split from https://github.com/rust-lang/rust/pull/127596#pullrequestreview-2171898588
2024-07-15 23:36:22 +00:00
Charles Celerier
deb8ebb39b Update name of Windows abort constant to match platform documentation 2024-07-15 22:21:41 +00:00
Charles Celerier
1aad89d11c Add match arm for Fuchsia status code upon an abort in a test
This change adds ZX_TASK_RETCODE_EXCEPTION_KILL as an expected status
code upon an abort in a test on Fuchsia. Tests

fixes #127539
2024-07-15 22:21:41 +00:00
Michael Goulet
841b30f63e Make sure trait def ids match before zipping args in note_function_argument_obligation 2024-07-15 17:53:22 -04:00
Matthias Krüger
4f9b59806b
Rollup merge of #127684 - RalfJung:unleashed-mutable-refs, r=oli-obk
consolidate miri-unleashed tests for mutable refs into one file

r? ```@oli-obk```
2024-07-15 21:11:48 +02:00
Matthias Krüger
2b82729b91
Rollup merge of #127407 - estebank:parser-suggestions, r=oli-obk
Make parse error suggestions verbose and fix spans

Go over all structured parser suggestions and make them verbose style.

When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
2024-07-15 21:11:48 +02:00
Matthias Krüger
78529d9841
Rollup merge of #124921 - RalfJung:offset-from-same-addr, r=oli-obk
offset_from: always allow pointers to point to the same address

This PR implements the last remaining part of the t-opsem consensus in https://github.com/rust-lang/unsafe-code-guidelines/issues/472: always permits offset_from when both pointers have the same address, no matter how they are computed. This is required to achieve *provenance monotonicity*.

Tracking issue: https://github.com/rust-lang/rust/issues/117945

### What is provenance monotonicity and why does it matter?

Provenance monotonicity is the property that adding arbitrary provenance to any no-provenance pointer must never make the program UB. More specifically, in the program state, data in memory is stored as a sequence of [abstract bytes](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#abstract-byte), where each byte can optionally carry provenance. When a pointer is stored in memory, all of the bytes it is stored in carry that provenance. Provenance monotonicity means: if we take some byte that does not have provenance, and give it some arbitrary provenance, then that cannot change program behavior or introduce UB into a UB-free program.

We care about provenance monotonicity because we want to allow the optimizer to remove provenance-stripping operations. Removing a provenance-stripping operation effectively means the program after the optimization has provenance where the program before the optimization did not -- since the provenance removal does not happen in the optimized program. IOW, the compiler transformation added provenance to previously provenance-free bytes. This is exactly what provenance monotonicity lets us do.

We care about removing provenance-stripping operations because `*ptr = *ptr` is, in general, (likely) a provenance-stripping operation. Specifically, consider `ptr: *mut usize` (or any integer type), and imagine the data at `*ptr` is actually a pointer (i.e., we are type-punning between pointers and integers). Then `*ptr` on the right-hand side evaluates to the data in memory *without* any provenance (because [integers do not have provenance](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html#integers-do-not-have-provenance)). Storing that back to `*ptr` means that the abstract bytes `ptr` points to are the same as before, except their provenance is now gone. This makes  `*ptr = *ptr`  a provenance-stripping operation  (Here we assume `*ptr` is fully initialized. If it is not initialized, evaluating `*ptr` to a value is UB, so removing `*ptr = *ptr` is trivially correct.)

### What does `offset_from` have to do with provenance monotonicity?

With `ptr = without_provenance(N)`, `ptr.offset_from(ptr)` is always well-defined and returns 0. By provenance monotonicity, I can now add provenance to the two arguments of `offset_from` and it must still be well-defined. Crucially, I can add *different* provenance to the two arguments, and it must still be well-defined. In other words, this must always be allowed: `ptr1.with_addr(N).offset_from(ptr2.with_addr(N))` (and it returns 0). But the current spec for `offset_from` says that the two pointers must either both be derived from an integer or both be derived from the same allocation, which is not in general true for arbitrary `ptr1`, `ptr2`.

To obtain provenance monotonicity, this PR hence changes the spec for offset_from to say that if both pointers have the same address, the function is always well-defined.

### What further consequences does this have?

It means the compiler can no longer transform `end2 = begin.offset(end.offset_from(begin))` into `end2 = end`. However, it can still be transformed into `end2 = begin.with_addr(end.addr())`, which later parts of the backend (when provenance has been erased) can trivially turn into `end2 = end`.

The only alternative I am aware of is a fundamentally different handling of zero-sized accesses, where a "no provenance" pointer is not allowed to do zero-sized accesses and instead we have a special provenance that indicates "may be used for zero-sized accesses (and nothing else)". `offset` and `offset_from` would then always be UB on a "no provenance" pointer, and permit zero-sized offsets on a "zero-sized provenance" pointer. This achieves provenance monotonicity. That is, however, a breaking change as it contradicts what we landed in https://github.com/rust-lang/rust/pull/117329. It's also a whole bunch of extra UB, which doesn't seem worth it just to achieve that transformation.

### What about the backend?

LLVM currently doesn't have an intrinsic for pointer difference, so we anyway cast to integer and subtract there. That's never UB so it is compatible with any relaxation we may want to apply.

If LLVM gets a `ptrsub` in the future, then plausibly it will be consistent with `ptradd` and [consider two equal pointers to be inbounds](https://github.com/rust-lang/rust/pull/124921#issuecomment-2205795829).
2024-07-15 21:11:47 +02:00
yukang
317952677a Suggest a borrow when using dbg 2024-07-16 02:48:47 +08:00
Michael Goulet
172cf9bef3 Fix unsoundness when associated types dont actually come from supertraits 2024-07-15 14:17:32 -04:00
Michael Goulet
8edf9b8084 Item bounds can reference self projections and still be object safe 2024-07-15 14:16:48 -04:00
Lzu Tao
bdc9df2478 Use multipart_suggestion to avoid place holder in span_to_snippet
CO-AUTHORED-BY: Esteban Küber <esteban@kuber.com.ar>
2024-07-15 12:54:00 +00:00
Lzu Tao
9c3c278b54 Add support for `Result<&T, _>' 2024-07-15 12:54:00 +00:00
Benoît du Garreau
772315de7c Remove generic lifetime parameter of trait Pattern
Use a GAT for `Searcher` associated type because this trait is always
implemented for every lifetime anyway.
2024-07-15 12:12:44 +02:00
Ulrich Weigand
636ddcb099 Ignore allocation bytes in one more mir-opt test
Following on PR #126502, add `rustc -Zdump-mir-exclude-alloc-bytes`
to tests/mir-opt/dataflow-const-prop/aggregate_copy.rs as well
to skip writing allocation bytes in MIR dumps.

Fixes #126261
2024-07-15 10:18:06 +02:00
Scott McMurray
eb3cc5f824 Use Option's discriminant as its size hint 2024-07-15 00:34:03 -07:00
Matthias Krüger
f19cb0b294
Rollup merge of #127711 - BoxyUwU:add_effects_test, r=fee1-dead
Add regression test for a gce + effects ICE

Fixes #125770

I'm not *exactly* sure why this stopped ICEing, I assume its something to do with the fact that there used to be a generic parameter on `Add` for the host generic and we have mismatched args here, which #125608 made no longer later cause issues. But now the desugaring is also different so? 🤷‍♀️

r? `@fee1-dead`
2024-07-14 20:25:00 +02:00
bors
88fa119c77 Auto merge of #127670 - compiler-errors:no-type-length-limit, r=jackh726
Gate the type length limit check behind a nightly flag

Effectively disables the type length limit by introducing a `-Zenforce-type-length-limit` which defaults to **`false`**, since making the length limit actually be enforced ended up having a worse fallout than expected. We still keep the code around, but the type length limit attr is now a noop (except for its usage in some diagnostics code?).

r? `@lcnr` -- up to you to decide what team consensus we need here since this reverses an FCP decision.

Reopens #125460 (if we decide to reopen it or keep it closed)
Effectively reverses the decision FCP'd in #125507
Closes #127346
2024-07-14 12:44:07 +00:00
Gurinder Singh
e13eb37eeb Fix malformed suggestion for repeated maybe unsized bounds 2024-07-14 17:46:25 +05:30
klensy
b90ee2a51a reenable some windows tests 2024-07-14 13:48:29 +03:00
bors
0ffbddd09e Auto merge of #127087 - cjgillot:small-map, r=oli-obk
Only track mentioned places for jump threading

This PR aims to reduce the state space size in jump threading and dataflow const-prop opts.

The current implementation walks the types of all locals, and creates a place for each possible projection. This can easily lead to a large number of places and tracked values, most being useless to the actual pass.

With this PR, we instead collect places that appear syntactically in the MIR (first commit). However, this is not sufficient (second commit), and we miss places that we could track in aggregate assignments. The third commit tracks such assignments to mirror place projections, see the inline comment.

This is complementary to https://github.com/rust-lang/rust/pull/127036

r? `@oli-obk`
2024-07-14 08:01:21 +00:00
Boxy
a54dbbfd0e add_effects_test 2024-07-14 07:57:53 +01:00
long-long-float
332b41dbce Use ordinal number in argument error
Fix error message

Fix tests

Format
2024-07-14 13:50:09 +09:00
Jubilee
6a3566c2b0
Rollup merge of #127671 - notriddle:notriddle/issue-d, r=Mark-Simulacrum
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 8)

Follow up

* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
* https://github.com/rust-lang/rust/pull/118105
* https://github.com/rust-lang/rust/pull/119561
* https://github.com/rust-lang/rust/pull/123574
* https://github.com/rust-lang/rust/pull/125382

As always, it's easier to review the commits one at a time. Don't use the Files Changed tab. It's confusing.
2024-07-13 20:19:48 -07:00
Jubilee
4c493db0d9
Rollup merge of #122300 - CastilloDel:master, r=cjgillot
Add FileCheck annotations to mir-opt/dest-prop tests

Part of https://github.com/rust-lang/rust/issues/116971, adds FileCheck annotations to MIR-opt tests in tests/mir-opt/dest-prop.

I would like some feedback. Also, I don't know how to approach `union.rs`.  I couldn't figure out what it is testing.

r? cjgillot
2024-07-13 20:19:45 -07:00
bors
25acbbd12f Auto merge of #127435 - GrigorenkoPV:tests-for-112905, r=cjgillot
Add tests for #112905

This is a part of #105107. Adds the tests from the OP in #112905.
2024-07-13 13:12:52 +00:00
Ralf Jung
90c9e32ad2 consolidate miri-unleashed tests for mutable refs into one file 2024-07-13 14:43:38 +02:00
Camille GILLOT
6e3cff7094 Bless coverage. 2024-07-13 12:02:12 +00:00
Camille GILLOT
7ac7f135e3 Propagate places through assignments. 2024-07-13 12:02:10 +00:00
Camille GILLOT
af876626b0 Add test for copying aggregates. 2024-07-13 11:54:30 +00:00
Camille GILLOT
76f5bc6a9f Create mapped places upon seeing them in the body. 2024-07-13 11:54:25 +00:00
bors
0065384608 Auto merge of #127397 - jyn514:multi-thread-panic-hook, r=workingjubilee
fix interleaved output in the default panic hook when multiple threads panic simultaneously

previously, we only held a lock for printing the backtrace itself. since all threads were printing to the same file descriptor, that meant random output in the default panic hook from one thread would be interleaved with the backtrace from another. now, we hold the lock for the full duration of the hook, and the output is ordered.

---

i noticed some odd things while working on this you may or may not already be aware of.

- libbacktrace is included as a submodule instead of a normal rustc crate, and as a result uses `cfg(backtrace_in_std)` instead of a more normal `cfg(feature = "rustc-dep-of-std")`. probably this is left over from before rust used a cargo-based build system?
- the default panic handler uses `trace_unsynchronized`, etc, in `sys::backtrace::print`. as a result, the lock only applies to concurrent *panic handlers*, not concurrent *threads*.  in other words, if another, non-panicking, thread tried to print a backtrace at the same time as the panic handler, we may have UB, especially on windows.
    - we have the option of changing backtrace to enable locking when `backtrace_in_std` is set so we can reuse their lock instead of trying to add our own.
2024-07-13 03:42:24 +00:00
Michael Howell
42ee400b0f Move assertion-free rustdoc ice tests to rustdoc-ui 2024-07-12 18:18:30 -07:00
Michael Goulet
938ed369ad Gate the type length limit check behind a nightly flag 2024-07-12 21:16:09 -04:00
Michael Howell
17419f6499 rustdoc: rename issue-\d+.rs tests to have meaningful names 2024-07-12 18:14:37 -07:00
Lzu Tao
9c1a9e03d5 add test for Result<&T, _> where T; Deref 2024-07-13 00:54:00 +00:00
Michael Howell
4d35754c46 Add URL and crate_name to test cases 2024-07-12 17:36:21 -07:00
bors
336e89bd15 Auto merge of #127665 - workingjubilee:rollup-g90yr21, r=workingjubilee
Rollup of 11 pull requests

Successful merges:

 - #126502 (Ignore allocation bytes in some mir-opt tests)
 - #126922 (add lint for inline asm labels that look like binary)
 - #127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate)
 - #127310 (Fix import suggestion ice)
 - #127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake)
 - #127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake)
 - #127535 (Fire unsafe_code lint on unsafe extern blocks)
 - #127619 (Suggest using precise capturing for hidden type that captures region)
 - #127631 (Remove `fully_normalize`)
 - #127632 (Implement `precise_capturing` support for rustdoc)
 - #127660 (Rename the internal `const_strlen` to just `strlen`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-12 22:59:30 +00:00
Jubilee
c0d949909f
Rollup merge of #127632 - compiler-errors:precise-capturing-rustdoc, r=fmease
Implement `precise_capturing` support for rustdoc

Implements rustdoc (+json) support for local (i.e. non-cross-crate-inlined) RPITs with `use<...>` precise capturing syntax.

Tests kinda suck. They're really hard to write 😰

r? `@fmease` or re-roll if you're too busy!
also cc `@aDotInTheVoid` for the json side

Tracking:
* https://github.com/rust-lang/rust/issues/127228#issuecomment-2201443216 (not fully fixed for cross-crate-inlined opaques)
* https://github.com/rust-lang/rust/issues/123432
2024-07-12 13:47:10 -07:00
Jubilee
20cf4eb3b0
Rollup merge of #127619 - compiler-errors:precise-capturing-better-sugg, r=oli-obk
Suggest using precise capturing for hidden type that captures region

Adjusts the "add `+ '_`" suggestion for opaques to instead suggest adding or reusing the `+ use<>` in the opaque.

r? oli-obk or please re-roll if you're busy!
2024-07-12 13:47:09 -07:00
Jubilee
2e0591b1e9
Rollup merge of #127535 - spastorino:unsafe_code-unsafe_extern_blocks, r=oli-obk
Fire unsafe_code lint on unsafe extern blocks

Fixes #126738
2024-07-12 13:47:08 -07:00
Jubilee
38c314e29d
Rollup merge of #127381 - Oneirical:testalt-consciousness, r=jieyouxu
Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try on musl.

try-job: dist-x86_64-musl
2024-07-12 13:47:08 -07:00
Jubilee
6cdef05a71
Rollup merge of #127338 - Oneirical:ready-your-arbatests, r=jieyouxu
Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: armhf-gnu
// try-job: test-various // already tried
try-job: x86_64-msvc
try-job: aarch64-apple
2024-07-12 13:47:07 -07:00
Jubilee
afb2fbf692
Rollup merge of #127310 - chenyukang:yukang-fix-suggest-import-ice, r=estebank
Fix import suggestion ice

Fixes #127302

#127302 only crash in edition 2015
#120074 can only reproduced in edition 2021
so I added revisions in test file.
2024-07-12 13:47:07 -07:00
Jubilee
a6a7129827
Rollup merge of #127209 - sayantn:xop, r=Amanieu
Added the `xop` target-feature and the `xop_target_feature` feature gate

This is an effort towards #127208. This adds the `xop` target feature gated by `xop_target_feature`.
2024-07-12 13:47:06 -07:00
Jubilee
fc0136e4f4
Rollup merge of #126922 - asquared31415:asm_binary_label, r=estebank
add lint for inline asm labels that look like binary

fixes #94426

Due to a bug/feature in LLVM, labels composed of only the digits `0` and `1` can sometimes be confused with binary literals, even if a binary literal would not be valid in that position.

This PR adds detection for such labels and also as a drive-by change, adds a note to cases such as `asm!(include_str!("file"))` that the label that it found came from an expansion of a macro, it wasn't found in the source code.

I expect this PR to upset some people that were using labels `0:` or `1:` without issue because they never hit the case where LLVM got it wrong, but adding a heuristic to the lint to prevent this is not feasible - it would involve writing a whole assembly parser for every target that we have assembly support for.

[zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-20/near/445870628)

r? ``@estebank``
2024-07-12 13:47:05 -07:00
Jubilee
5d56572f06
Rollup merge of #126502 - cuviper:dump-mir-exclude-alloc-bytes, r=estebank
Ignore allocation bytes in some mir-opt tests

This adds `rustc -Zdump-mir-exclude-alloc-bytes` to skip writing allocation bytes in MIR dumps, and applies it to tests that were failing on s390x due to its big-endian byte order.

Fixes #126261
2024-07-12 13:47:05 -07:00
Oneirical
b98365871f rewrite raw-dylib-custom-dlltool to rmake 2024-07-12 16:41:28 -04:00
bors
c6727fc9b5 Auto merge of #123351 - beetrees:x86-ret-snan-rust, r=nikic,workingjubilee
Ensure floats are returned losslessly by the Rust ABI on 32-bit x86

Solves #115567 for the (default) `"Rust"` ABI. When compiling for 32-bit x86, this PR changes the `"Rust"` ABI to return floats indirectly instead of in x87 registers (with the exception of single `f32`s, which this PR returns in general purpose registers as they are small enough to fit in one). No change is made to the `"C"` ABI as that ABI requires x87 register usage and therefore will need a different solution.
2024-07-12 20:36:43 +00:00
Esteban Küber
cf09cba20c When finding item gated behind a cfg flat, point at it
Previously we would only mention that the item was gated out, and opportunisitically mention the feature flag name when possible. We now point to the place where the item was gated, which can be behind layers of macro indirection, or in different modules.

```
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
  --> $DIR/diagnostics-cross-crate.rs:18:23
   |
LL |     cfged_out::inner::doesnt_exist::hello();
   |                       ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
   |
note: found an item that was configured out
  --> $DIR/auxiliary/cfged_out.rs:6:13
   |
LL |     pub mod doesnt_exist {
   |             ^^^^^^^^^^^^
note: the item is gated here
  --> $DIR/auxiliary/cfged_out.rs:5:5
   |
LL |     #[cfg(FALSE)]
   |     ^^^^^^^^^^^^^
```
2024-07-12 18:52:52 +00:00
Pavel Grigorenko
168096f663 rustc_type_ir: derivative -> derive-where 2024-07-12 21:52:04 +03:00
sayantn
1fd0311eab Added the xop target feature and xop_target_feature gate 2024-07-12 23:30:22 +05:30
jyn
1c8f9bb84d fix interleaved panic output
previously, we only held a lock for printing the backtrace itself. since all threads were printing to the same file descriptor, that meant random output in the default panic hook would be interleaved with the backtrace. now, we hold the lock for the full duration of the hook, and the output is ordered.
2024-07-12 11:52:04 -04:00
Oneirical
fe76650144 rewrite env-dep-info to rmake 2024-07-12 10:58:20 -04:00
Oneirical
87c7a42ba9 rewrite rustc-macro-dep-files to rmake 2024-07-12 10:57:58 -04:00
Oneirical
f768db6ba6 rewrite and rename issue-83045 to rmake 2024-07-12 10:57:57 -04:00
Oneirical
c6cdbe635b rewrite and rename issue-85019-moved-src-dir to rmake 2024-07-12 10:45:39 -04:00
Oneirical
cef8a044ea rewrite extra-filename-with-temp-outputs to rmake 2024-07-12 10:45:38 -04:00
Matthias Krüger
18152d72a4
Rollup merge of #126639 - sayantn:amx, r=Amanieu
Add AMX target-features and `x86_amx_intrinsics` feature flag

This is an effort towards #126622. This adds support for all 5 target-features for `AMX`, and introduces the feature flag `x86_amx_intrinsics`, which would gate these target-features and the yet-to-be-implemented amx intrinsics in stdarch.
2024-07-12 14:37:57 +02:00
beetrees
cae9d480bf
Adjust tests for x86 "Rust" ABI changes 2024-07-12 10:47:56 +01:00
Michael Goulet
bd135e487f Add rustdoc-json support for use<> 2024-07-12 05:24:51 -04:00
Michael Goulet
843f5dd93b Add rustdoc support for use<> in (local) RPITs 2024-07-12 05:24:51 -04:00
Lzu Tao
5e1cabe982 Add suggestion to use Option::map_or over erroneous Option::unwrap_or 2024-07-12 08:43:28 +00:00
Lzu Tao
abeb7203e4 Add regression test for issue 127545 2024-07-12 08:16:08 +00:00
bors
b286722878 Auto merge of #127635 - matthiaskrgr:rollup-foopajr, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #127164 (match lowering: Clarify the main loop of the algorithm)
 - #127422 (as_simd: fix doc comment to be in line with align_to)
 - #127596 (More suggestion for converting `Option<&Vec<T>>` to `Option<&[T]>`)
 - #127607 (compiletest: Better error message for bad `normalize-*` headers)
 - #127622 (Mark `builtin_syntax` as internal)
 - #127625 (Revert accidental comment deletion)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-12 03:40:38 +00:00
Esteban Küber
71f16bdb32 Make ; suggestions inline 2024-07-12 03:22:32 +00:00
Esteban Küber
377d14be88 More accurate incorrect use of await suggestion 2024-07-12 03:02:58 +00:00
Esteban Küber
b5f94c61f7 Use more accurate span for : to :: suggestion 2024-07-12 03:02:58 +00:00
Esteban Küber
dd40e0b4ee Tweak tests to avoid confusing suggestion output 2024-07-12 03:02:57 +00:00
Esteban Küber
c2b3287483 Make impl and ! removal suggestion short 2024-07-12 03:02:57 +00:00
Esteban Küber
692bc344d5 Make parse error suggestions verbose and fix spans
Go over all structured parser suggestions and make them verbose style.

When suggesting to add or remove delimiters, turn them into multiple suggestion parts.
2024-07-12 03:02:57 +00:00
sayantn
ec05c4ea3f Add the feature gate and target-features 2024-07-11 19:00:49 -07:00
Matthias Krüger
83d1a1b252
Rollup merge of #127596 - tesuji:help-unwrap-or, r=compiler-errors
More suggestion for converting `Option<&Vec<T>>` to `Option<&[T]>`

Please review commit-by-commit.
2024-07-12 03:43:35 +02:00
Matthias Krüger
58fe37f2c3
Rollup merge of #127164 - Nadrieril:clean-lowering-loop, r=matthewjasper
match lowering: Clarify the main loop of the algorithm

Now that we expand or-patterns in a single place in the algorithm, we can move it (back) to the main part of the loop. This makes the call-graph of the main loop rather simple: `match_candidates` has three branches that each call back to `match_candidates`. The remaining tricky part is `finalize_or_candidate`.

I also factored out the whole "process a prefix of the candidates then process the rest" thing which I think helps legibility.

The first two commits are a fix for an indexing mistake I introduced in https://github.com/rust-lang/rust/pull/126553, already sumitted in https://github.com/rust-lang/rust/pull/127028 but feel free to merge this first.

r? `@matthewjasper`
2024-07-12 03:43:34 +02:00
bors
4a31a6c32a Auto merge of #127382 - estebank:const-let, r=compiler-errors
Use verbose style when suggesting changing `const` with `let`
2024-07-12 01:18:12 +00:00
Lzu Tao
872d7b82e1 Add suggestion for Option<&Vec<T>> -> Option<&[T] 2024-07-11 22:50:23 +00:00
Lzu Tao
d9170dc666 Add regression test for issue 127545 2024-07-11 22:50:23 +00:00
Esteban Küber
4df75140dd Fix aarch64 test 2024-07-11 20:40:02 +00:00
Esteban Küber
cbe75486f7 Account for let foo = expr; to suggest const foo: Ty = expr; 2024-07-11 20:39:24 +00:00
Esteban Küber
b56dc8ee90 Use verbose style when suggesting changing const with let 2024-07-11 20:39:24 +00:00
Michael Goulet
03bee1e1e5 Suggest using precise capturing for hidden type that captures region 2024-07-11 14:01:29 -04:00
Matthias Krüger
fa3ce50f0b
Rollup merge of #127605 - nikic:remove-extern-wasm, r=oli-obk
Remove extern "wasm" ABI

Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked in #83788).

As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679 and following, this ABI is a failed experiment that did not end up being used for anything. Keeping support for this ABI in LLVM 19 would require us to switch wasm targets to the `experimental-mv` ABI, which we do not want to do.

It should be noted that `Abi::Wasm` was internally used for two things: The `-Z wasm-c-abi=legacy` ABI that is still used by default on some wasm targets, and the `extern "wasm"` ABI. Despite both being `Abi::Wasm` internally, they were not the same. An explicit `extern "wasm"` additionally enabled the `+multivalue` feature.

I've opted to remove `Abi::Wasm` in this patch entirely, instead of keeping it as an ABI with only internal usage. Both `-Z wasm-c-abi` variants are now treated as part of the normal C ABI, just with different different treatment in
adjust_for_foreign_abi.
2024-07-11 17:01:41 +02:00
Matthias Krüger
d433f176ef
Rollup merge of #127601 - trevyn:issue-127600, r=compiler-errors
check is_ident before parse_ident

Closes #127600
2024-07-11 17:01:40 +02:00
Matthias Krüger
a10b4d1463
Rollup merge of #127598 - weiznich:diagnostic_do_not_recommend_also_skips_help, r=compiler-errors
Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well

This commit changes the error reporting mechanism for not implemented traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the help part of the error message ("the following other types implement trait `Foo`:"). The main use case here is to allow crate authors to skip non-meaningful confusing suggestions. A common example for this are fully generic impls on tuples.

Related to https://github.com/rust-lang/rust/issues/51992

r? `@compiler-errors`
2024-07-11 17:01:39 +02:00
Matthias Krüger
73c500b3a7
Rollup merge of #127591 - compiler-errors:label-after-primary, r=lcnr
Make sure that labels are defined after the primary span in diagnostics

Putting a `#[label]` before a `#[primary_span]` results in that label being overwritten, due to the semantics of `Diagnostic::span` and the fact that labels are stored in the `MultiSpan` of the diagnostic.

This isn't possible to fix in general, since a lot of code actually *relies* in this overwriting behavior (e.g. `rustc_on_unimplemented`). However, it's useful to enforce this for derive-diagnostics, since this is certainly never what you intend to do in a derived diagnostic, where all the fields are meaningful parts of the diagnostic being rendered.

This only matters for `#[label]`, since those are the ones stored in the `MultiSpan` of the error.

We could also make this "just work" by sorting the attrs or processing the primary span attr first, however I think it's kinda pointless to do.

There was 1 case where this mattered, but we literally didn't have a test exercising that diagnostic 🙃
2024-07-11 17:01:38 +02:00
Matthias Krüger
8de487fdbd
Rollup merge of #124599 - estebank:issue-41708, r=wesleywiser
Suggest borrowing on fn argument that is `impl AsRef`

When encountering a move conflict, on an expression that is `!Copy` passed as an argument to an `fn` that is `impl AsRef`, suggest borrowing the expression.

```
error[E0382]: use of moved value: `bar`
  --> f204.rs:14:15
   |
12 |     let bar = Bar;
   |         --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait
13 |     foo(bar);
   |         --- value moved here
14 |     let baa = bar;
   |               ^^^ value used here after move
   |
help: borrow the value to avoid moving it
   |
13 |     foo(&bar);
   |         +
```

Fix #41708
2024-07-11 17:01:36 +02:00
bors
c92a8e4d4d Auto merge of #127311 - oli-obk:do_not_count_errors, r=compiler-errors
Avoid follow-up errors and ICEs after missing lifetime errors on data structures

Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result.

Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place.

I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists).

fixes #124262
fixes #124083
fixes #125155
fixes #125888
fixes #125992
fixes #126666
fixes #126648
fixes #127268
fixes #127266
fixes #127304
2024-07-11 11:51:33 +00:00
Oli Scherer
dce98c52ff Avoid follow-up errors and ICEs after missing lifetime errors on data structures 2024-07-11 11:00:15 +00:00
Nikita Popov
8a50bcbdce Remove extern "wasm" ABI
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked
in #83788).

As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679
and following, this ABI is a failed experiment that did not end
up being used for anything. Keeping support for this ABI in LLVM 19
would require us to switch wasm targets to the `experimental-mv`
ABI, which we do not want to do.

It should be noted that `Abi::Wasm` was internally used for two
things: The `-Z wasm-c-abi=legacy` ABI that is still used by
default on some wasm targets, and the `extern "wasm"` ABI. Despite
both being `Abi::Wasm` internally, they were not the same. An
explicit `extern "wasm"` additionally enabled the `+multivalue`
feature.

I've opted to remove `Abi::Wasm` in this patch entirely, instead
of keeping it as an ABI with only internal usage. Both
`-Z wasm-c-abi` variants are now treated as part of the normal
C ABI, just with different different treatment in
adjust_for_foreign_abi.
2024-07-11 12:20:26 +02:00
bors
fdf7ea6b5b Auto merge of #126777 - Zalathar:normalize-colon, r=lcnr
Require a colon in `//@ normalize-*:` test headers

The previous parser for `//@ normalize-*` headers (before #126370) was so lax that it did not require `:` after the header name. As a result, the test suite contained a mix of with-colon and without-colon normalize headers, both numbering in the hundreds.

This PR updates the without-colon headers to add a colon (matching the style used by other headers), and then updates the parser to make the colon mandatory.

(Because the normalization parser only runs *after* the header system identifies a normalize header, this will detect and issue an error for relevant headers that lack the colon.)

Addresses one of the points of #126372.
2024-07-11 09:13:15 +00:00
trevyn
a01f49e7f3 check is_ident before parse_ident 2024-07-11 12:12:00 +04:00
bors
9b0043095a Auto merge of #127097 - compiler-errors:async-closure-lint, r=oli-obk
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure

We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.

Tracking:
* #62290
2024-07-11 06:59:10 +00:00
Georg Semmler
27d5db166e
Allows #[diagnostic::do_not_recommend] to supress trait impls in suggestions as well
This commit changes the error reporting mechanism for not implemented
traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the
help part of the error message ("the following other types implement
trait `Foo`:"). The main use case here is to allow crate authors to skip
non-meaningful confusing suggestions. A common example for this are
fully generic impls on tuples.
2024-07-11 08:14:28 +02:00
Michael Goulet
de88bc5c89 And additionally enforce ? and async/const aren't mixed 2024-07-11 00:00:03 -04:00
bors
8c39ac9ecc Auto merge of #127575 - chenyukang:yukang-fix-struct-fields-ice, r=compiler-errors
Avoid "no field" error and ICE on recovered ADT variant

Fixes https://github.com/rust-lang/rust/issues/126744
Fixes https://github.com/rust-lang/rust/issues/126344, a more general fix compared with https://github.com/rust-lang/rust/pull/127426

r? `@oli-obk`

From `@compiler-errors` 's comment https://github.com/rust-lang/rust/pull/127502#discussion_r1669538204
Seems most of the ADTs don't have taint, so maybe it's not proper to change `TyCtxt::type_of` query.
2024-07-11 03:12:38 +00:00
Zalathar
9aaa0c5867 Always use a colon in //@ normalize-*: headers 2024-07-11 12:23:44 +10:00
bors
e1f45a1442 Auto merge of #127538 - Oneirical:the-sacred-tests, r=jieyouxu
Migrate `issue-83112-incr-test-moved-file`, `type-mismatch-same-crate-name` and `issue-109934-lto-debuginfo` `run-make` tests to rmake or ui

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

I have noticed that the new UI test `debuginfo-lto-alloc` is outputting artifacts that aren't getting cleaned up because of its `-C incremental`. That might be the justification needed to keep it as a run-make test?

Try it on:

// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc
2024-07-11 00:56:46 +00:00
Michael Goulet
12ae282987 Fix diagnostic and add a test for it 2024-07-10 18:56:06 -04:00
Urgau
de560c3065 Implement ambiguous_negative_literals lint 2024-07-11 00:46:47 +02:00
Michael Goulet
898ed2ffa6 Enforce that ? and for<...> are not combined 2024-07-10 17:49:50 -04:00
Michael Goulet
32c8bfdb11 Improve error message 2024-07-10 17:15:02 -04:00
Michael Goulet
e8445818d4 Reorder modifiers and polarity to be *after* binder in trait bounds 2024-07-10 17:15:02 -04:00
bors
0c81f94b9a Auto merge of #127419 - trevyn:issue-125446, r=fee1-dead
Add suggestions for possible missing `fn`, `struct`, or `enum` keywords

Closes #125446
Closes #65381
2024-07-10 18:27:32 +00:00
yukang
07e6dd95bd report pat no field error no recoverd struct variant 2024-07-11 00:18:47 +08:00
Ralf Jung
287b66b0b5 size_of_val_raw: for length 0 this is safe to call 2024-07-10 18:01:06 +02:00
Matthias Krüger
7faef5d5ed
Rollup merge of #127568 - lcnr:undo-leakcheck, r=oli-obk
instantiate higher ranked goals in candidate selection again

This reverts #119820 as that PR has a significant impact and breaks code which *feels like it should work*. The impact ended up being larger than we expected during the FCP and we've ended up with some ideas for how we can work around this issue in the next solver. This has been discussed in the previous high bandwidth t-types meeting: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2024-07-09.20high.20bandwidth.20meeting.

We'll therefore keep this inconsistency between the two solvers for now and will have to deal with it before stabilizating the use of the new solver outside of coherence: https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.

fixes #125194 after a beta-backport.

The pattern which is more widely used than expected and feels like it should work, especially without deep knowledge of the type system is
```rust
trait Trait<'a> {}
impl<'a, T> Trait<'a> for T {}

fn trait_bound<T: for<'a> Trait<'a>>() {}

// A function with a where-bound which is more restrictive than the impl.
fn function1<T: Trait<'static>>() {
    // stable: ok
    // with #119820: error as we prefer the where-bound over the impl
    // with this PR: back to ok
    trait_bound::<T>();
}

```

r? `@rust-lang/types`
2024-07-10 17:54:28 +02:00
Matthias Krüger
a7fe30d82a
Rollup merge of #127094 - Borgerr:E0191-suggestion-correction, r=fmease
E0191 suggestion correction, inserts turbofish

closes #91997
2024-07-10 17:54:26 +02:00
lcnr
fe0bd76a8b elaborate unknowable goals
if a trait is unknowable, but its super trait
is definitely not implemented, then the trait
itself is definitely also not implemented.
2024-07-10 16:16:48 +02:00
lcnr
f77394fdf3 instantiate higher ranked goals in candidate selection
reverts #119820
2024-07-10 14:13:16 +02:00
bors
0fdfb61795 Auto merge of #127006 - Oneirical:holmes-the-detestive, r=Kobzol
Migrate `extern-flag-pathless`, `silly-file-names`, `metadata-dep-info`, `cdylib-fewer-symbols` and `symbols-include-type-name` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

`cdylib-fewer-symbols` demands a Windows try-job. (Almost guaranteed to fail, but 7 years is a long time)

try-job: x86_64-gnu-distcheck
try-job: x86_64-msvc
try-job: aarch64-apple
2024-07-10 08:51:20 +00:00
bors
649feb9c1a Auto merge of #127549 - jhpratt:rollup-o1mbmhr, r=jhpratt
Rollup of 8 pull requests

Successful merges:

 - #124211 (Bump `elided_lifetimes_in_associated_constant` to deny)
 - #125627 (migration lint for `expr2024` for the edition 2024)
 - #127091 (impl FusedIterator and a size hint for the error sources iter)
 - #127461 (Fixup failing fuchsia tests)
 - #127484 (`#[doc(alias)]`'s doc: say that ASCII spaces are allowed)
 - #127508 (small search graph refactor)
 - #127521 (Remove spastorino from SMIR)
 - #127532 (documentation: update cmake version)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-10 06:35:04 +00:00
Jacob Pratt
74907296d8
Rollup merge of #127461 - c6c7:fixup-failing-fuchsia-tests, r=tmandry
Fixup failing fuchsia tests

The Fuchsia platform passes all tests with these changes. Two tests are ignored because they rely on Fuchsia not returning a status code upon a process aborting. See #102032 and #58590 for more details on that topic.

Many formatting changes are also included in this PR.

r? tmandry
r? erickt
2024-07-10 00:37:11 -04:00
Jacob Pratt
21a0e86234
Rollup merge of #125627 - vincenzopalazzo:macros/cargo-fix-expr2024, r=compiler-errors,eholk
migration lint for `expr2024` for the edition 2024

This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr

Issue https://github.com/rust-lang/rust/issues/123742

I created also a repository to test out the migration https://github.com/vincenzopalazzo/expr2024-cargo-fix-migration

Co-Developed-by: ``@eholk``
2024-07-10 00:37:10 -04:00
bors
7caf6726db Auto merge of #127496 - tgross35:f16-f128-pattern-fixme, r=Nadrieril
Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY`

Just a small fix to the pattern matching tests now that we can. Also contains a small unrelated comment tweak.
2024-07-10 04:20:32 +00:00
Ashton Hunt
7c88bda1cb E0191 suggestion correction, inserts turbofish without dyn (#91997) 2024-07-09 17:21:31 -06:00
bors
7d640b670e Auto merge of #127358 - oli-obk:taint_itemctxt, r=fmease
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on https://github.com/rust-lang/rust/pull/127357

r? `@fmease`
2024-07-09 23:03:01 +00:00
Alan Egerton
f96f68f2ec
Test that --print link-args ends in newline 2024-07-09 23:07:38 +01:00
Charles Celerier
479b0cdb89 Ignore fuchsia tests implicitly relying on a signal upon abort
Both test-panic-abort-nocapture.rs and test-panic-abort.rs assert the
stderr output of the test. On Fuchsia, if a test fails an assertion,
this output will contain a line noting the process returned the code
-1028 (ZX_TASK_RETCODE_EXCEPTION_KILL). But the asserted stderr output
lacks this note. Presumably this is because other platforms implement
-Cpanic=abort by killing the process instead of returned a status
code.
2024-07-09 14:20:52 -07:00
Oneirical
2adfa147d7 rewrite issue-109934-lto-debuginfo as an ui test 2024-07-09 16:52:17 -04:00
Nadrieril
3e030b38ef Return the otherwise_block instead of passing it as argument
This saves a few blocks and matches the common `unpack!` paradigm.
2024-07-09 22:47:35 +02:00
Nadrieril
8a222ffd6b Don't try to save an extra block
This is preparation for the next commit.
2024-07-09 22:47:35 +02:00
Santiago Pastorino
a3ef94e80e
Fire unsafe_code lint on unsafe extern blocks 2024-07-09 17:35:51 -03:00
Oneirical
80fb4cab4e rewrite type-mismatch-same-crate-name to rmake 2024-07-09 16:34:22 -04:00
bors
6be96e3865 Auto merge of #127234 - ZhuUx:inlined-expr, r=davidtwco,Zalathar
[Coverage][MCDC] Group mcdc tests and fix panic when generating mcdc code for inlined expressions.

### Changes

1. Group all mcdc tests to one directory.
2. Since mcdc instruments different mappings for boolean expressions with normal branch coverage as #125766 introduces, it would be better also trace branch coverage results in mcdc tests.
3. So far rustc does not call `CoverageInfoBuilderMethods::init_coverage` for inlined functions. As a result, it could panic if it tries to instrument mcdc statements for inlined functions due to uninitialized cond bitmaps. We can reproduce this issue by current nightly rustc and [the test](https://github.com/rust-lang/rust/pull/127234/files#diff-c81af6bf4869aa42f5c7334e3e86344475de362f673f54ce439ec75fcb5ac3e5) with flag `--release`. This patch fixes it.
2024-07-09 20:24:30 +00:00
Oneirical
37599b2072 rewrite and rename issue-83112-incr-test-moved-file to rmake 2024-07-09 16:13:45 -04:00
Oneirical
d44732120c rewrite symbols-include-type-name to rmake 2024-07-09 14:30:57 -04:00
Vincenzo Palazzo
568e78f366 tests: adds cargo fix tests
Co-Developed-by: Eric Holk
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2024-07-09 17:41:13 +00:00
bors
9dcaa7f92c Auto merge of #127028 - Nadrieril:fix-or-pat-expansion, r=matthewjasper
Fix regression in the MIR lowering of or-patterns

In https://github.com/rust-lang/rust/pull/126553 I made a silly indexing mistake and regressed the MIR lowering of or-patterns. This fixes it.

r? `@compiler-errors` because I'd like this to be merged quickly 🙏
2024-07-09 16:33:59 +00:00
bors
8672b2b763 Auto merge of #127001 - beetrees:f16-debuginfo, r=michaelwoerister
Add Natvis visualiser and debuginfo tests for `f16`

To render `f16`s in debuggers on MSVC targets, this PR changes the compiler to output `f16`s as `struct f16 { bits: u16 }`, and includes a Natvis visualiser that manually converts the `f16`'s bits to a `float` which is can then be displayed by debuggers. `gdb`, `lldb` and `cdb` tests are also included for `f16` .

`f16`/`f128` MSVC debug info issue: #121837
Tracking issue: #116909
2024-07-09 09:07:42 +00:00
Oli Scherer
fd9a92542c Automatically taint when reporting errors from ItemCtxt 2024-07-09 07:44:17 +00:00
bors
5be2ec7245 Auto merge of #127200 - fee1-dead-contrib:trait_def_const_trait, r=compiler-errors
Add `constness` to `TraitDef`

Second attempt at fixing the regression @ https://github.com/rust-lang/rust/pull/120639#issuecomment-2198373716

r? project-const-traits
2024-07-09 06:51:35 +00:00
zhuyunxing
83fa6b726a coverage. Fix panic when generating mcdc code for inlined functions 2024-07-09 14:28:40 +08:00
zhuyunxing
c77788f011 coverage. MCDC tests also report branches coverage 2024-07-09 14:28:40 +08:00
zhuyunxing
4f6140258f coverage. Group mcdc tests in one directory 2024-07-09 14:28:40 +08:00
beetrees
b058de90a3
Add Natvis visualiser and debuginfo tests for f16 2024-07-09 03:47:50 +01:00
bors
99b7134389 Auto merge of #127378 - Oneirical:cetestial-meteorite, r=jieyouxu
Migrate `issue-37839`, `track-path-dep-info` and `track-pgo-dep-info` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: test-various
try-job: dist-x86_64-musl
2024-07-09 02:17:37 +00:00
asquared31415
87856c4461 add lint for inline asm labels that look like binary 2024-07-09 01:23:49 +00:00
bors
d4a620058b Auto merge of #127328 - Oneirical:yield-to-petestrians, r=jieyouxu
Migrate `pass-linker-flags-flavor`, `pass-linker-flags-from-dep` and `pass-linker-flags` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please test on i686-msvc. Expected to fail.

try-job: aarch64-apple
2024-07-08 23:07:51 +00:00
Trevor Gross
321eba5e8f Update f16/f128 FIXMEs that needed (NEG_)INFINITY 2024-07-08 18:02:14 -04:00
Guillaume Gomez
72199b2c52
Rollup merge of #127482 - compiler-errors:closure-two-par-sig-inference, r=oli-obk
Infer async closure signature from (old-style) two-part `Fn` + `Future` bounds

When an async closure is passed to a function that has a "two-part" `Fn` and `Future` trait bound, like:

```rust
use std::future::Future;

fn not_exactly_an_async_closure(_f: F)
where
    F: FnOnce(String) -> Fut,
    Fut: Future<Output = ()>,
{}
```

The we want to be able to extract the signature to guide inference in the async closure, like:

```rust
not_exactly_an_async_closure(async |string| {
    for x in string.split('\n') { ... }
    //~^ We need to know that the type of `string` is `String` to call methods on it.
})
```

Closure signature inference will see two bounds: `<?F as FnOnce<Args>>::Output = ?Fut`, `<?Fut as Future>::Output = String`. We need to extract the signature by looking through both projections.

### Why?

I expect the ecosystem's move onto `async Fn` trait bounds (which are not affected by this PR, and already do signature inference fine) to be slow. In the mean time, I don't see major overhead to supporting this "old–style" of trait bounds that were used to model async closures.

r? oli-obk
Fixes #127468
Fixes #127425
2024-07-08 20:23:41 +02:00
Guillaume Gomez
081cca13bd
Rollup merge of #127325 - Oneirical:gothic-testhetic, r=jieyouxu
Migrate `target-cpu-native`,  `target-specs` and `target-without-atomic-cas` `run-make` tests to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please test on i686-msvc.

try-job: i686-msvc
2024-07-08 20:23:40 +02:00
Guillaume Gomez
485a861a9f
Rollup merge of #127237 - GuillaumeGomez:improve-run-make-llvm-ident, r=Kobzol
Improve code of `run-make/llvm-ident`

Follow-up of https://github.com/rust-lang/rust/pull/126941.

r? `@Kobzol`
2024-07-08 20:23:39 +02:00
Guillaume Gomez
9804cf9b5d
Rollup merge of #126427 - Oneirical:oktobertest, r=jieyouxu
Rewrite `intrinsic-unreachable`, `sepcomp-cci-copies`, `sepcomp-inlining` and `sepcomp-separate` `run-make` tests to rmake.rs

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
2024-07-08 20:23:39 +02:00
Guillaume Gomez
aa1c24a908 Improve code of run-make/llvm-ident 2024-07-08 20:18:21 +02:00
Michael Goulet
f4f678f27e Infer async closure signature from old-style two-part Fn + Future bounds 2024-07-08 12:56:54 -04:00
bors
a06e9c83f6 Auto merge of #127486 - matthiaskrgr:rollup-lvv018b, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #120248 (Make casts of pointers to trait objects stricter)
 - #127355 (Mark format! with must_use hint)
 - #127399 (Verify that allocations output by GVN are sufficiently aligned.)
 - #127460 (clarify `sys::unix::fd::FileDesc::drop` comment)
 - #127467 (bootstrap: once_cell::sync::Lazy -> std::sync::LazyLock)

Failed merges:

 - #127357 (Remove `StructuredDiag`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-08 16:01:38 +00:00
Oneirical
7c23872836 rewrite track-pgo-dep-info to rmake 2024-07-08 10:31:05 -04:00
Matthias Krüger
3e8e8df7c0
Rollup merge of #127399 - cjgillot:issue-127396, r=oli-obk
Verify that allocations output by GVN are sufficiently aligned.

Fixes #127396

r? `@oli-obk`
2024-07-08 16:28:16 +02:00
Matthias Krüger
5b6eb28bda
Rollup merge of #127355 - aceArt-GmbH:126475, r=oli-obk
Mark format! with must_use hint

Uses unstable feature https://github.com/rust-lang/rust/issues/94745

Part of #126475

First contribution to rust, please let me know if the blessing of tests is correct
Thanks `@bjorn3` for the help
2024-07-08 16:28:15 +02:00
Matthias Krüger
c4ee2df539
Rollup merge of #120248 - WaffleLapkin:bonk-ptr-object-casts, r=compiler-errors,oli-obk,lnicola
Make casts of pointers to trait objects stricter

This is an attempt to `fix` https://github.com/rust-lang/rust/issues/120222 and https://github.com/rust-lang/rust/issues/120217.

This is done by adding restrictions on casting pointers to trait objects.

Before this PR the rules were as follows:

> When casting `*const X<dyn A>` -> `*const Y<dyn B>`, principal traits in `A` and `B` must refer to the same trait definition (or no trait).

With this PR the rules are changed to

> When casting `*const X<dyn Src>` -> `*const Y<dyn Dst>`
> - if `Dst` has a principal trait `DstP`,
>   - `Src` must have a principal trait `SrcP`
>   - `dyn SrcP` and `dyn DstP` must be the same type (modulo the trait object lifetime, `dyn T+'a` -> `dyn T+'b` is allowed)
>   - Auto traits in `Dst` must be a subset of auto traits in `Src`
>     - Not adhering to this is currently a FCW (warn-by-default + `FutureReleaseErrorReportInDeps`), instead of an error
> - if `Src` has a principal trait `Dst` must as well
>   - this restriction will be removed in a follow up PR

This ensures that
1. Principal trait's generic arguments match (no `*const dyn Tr<A>` -> `*const dyn Tr<B>` casts, which are a problem for [#120222](https://github.com/rust-lang/rust/issues/120222))
2. Principal trait's lifetime arguments match (no `*const dyn Tr<'a>` -> `*const dyn Tr<'b>` casts, which are a problem for [#120217](https://github.com/rust-lang/rust/issues/120217))
3. No auto traits can be _added_ (this is a problem for arbitrary self types, see [this comment](https://github.com/rust-lang/rust/pull/120248#discussion_r1463835350))

Some notes:
 - We only care about the metadata/last field, so you can still cast `*const dyn T` to `*const WithHeader<dyn T>`, etc
- The lifetime of the trait object itself (`dyn A + 'lt`) is not checked, so you can still cast `*mut FnOnce() + '_` to `*mut FnOnce() + 'static`, etc
  - This feels fishy, but I couldn't come up with a reason it must be checked

The diagnostics are currently not great, to say the least, but as far as I can tell this correctly fixes the issues.

cc `@oli-obk` `@compiler-errors` `@lcnr`
2024-07-08 16:28:15 +02:00
Oneirical
0d85ef2857 rewrite target-without-atomic-cas to rmake 2024-07-08 10:20:42 -04:00