Commit graph

261126 commits

Author SHA1 Message Date
许杰友 Jieyou Xu (Joe)
3e77f7c9a5 compiletest/rmake: prune unused RUST_BUILD_STAGE and explain env vars passed to recipes 2024-07-20 09:20:32 +00:00
许杰友 Jieyou Xu (Joe)
993d83af71 compiletest/rmake: cleanup stage_std_path and recipe_dylib_search_paths handling 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
aa22102f2f compiletest/rmake: better explain why stage0 sysroot is needed if forced stage0 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
2383e9dd4f compiletest/rmake: prune useless env vars and explain passed rustc options and env vars 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
f5488f0c4b compiletest/rmake: rename cmd to rustc 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
cf5edfe3f9 compiletest/rmake: cleanup rmake exe extension calculation 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
9f2a660f86 compiletest/rmake: cleanup library search paths 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
49ca9ff0ac compiletest/rmake: cleanup dylib search paths related calculations 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
01ed951f8b compiletest/rmake: improve clarity of support_lib_{path,deps,deps_deps} calculations 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
2eb8810d32 compiletest/rmake: move stage_std_path and recipe_bin closer to use site 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
6ca31099e3 compiletest/rmake: improve stage explanation 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
23f32f44dd compiletest/rmake: make {source,build}_root path calculation more robust for rmake.rs setup 2024-07-19 14:04:58 +00:00
许杰友 Jieyou Xu (Joe)
1b4972bc28 compiletest/rmake: adjust docs for rmake.rs setup and add FIXMEs 2024-07-19 13:53:56 +00: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
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
314cf1fc7a
Rollup merge of #127953 - bzEq:aix-compiletest-dylib-suffix, r=jieyouxu
[compiletest] Search *.a when getting dynamic libraries on AIX

AIX uses `.a` as dylib suffix. Support it in compiletest.
2024-07-19 03:27:50 -05: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
41557426c5
Rollup merge of #127902 - nnethercote:collect_tokens_trailing_token-cleanups, r=petrochenkov
`collect_tokens_trailing_token` cleanups

More cleanups I made while understanding the code for processing `cfg_attr`, to fix test failures in #124141.

r? `@petrochenkov`
2024-07-19 03:27:48 -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
Trevor Gross
986d6bf9fb
Rollup merge of #121533 - ratmice:wasm_init_fini_array, r=nnethercote
Handle .init_array link_section specially on wasm

Given that wasm-ld now has support for [.init_array](8f2bd8ae68/llvm/lib/MC/WasmObjectWriter.cpp (L1852)), it appears we can easily implement that section by falling through to the normal path rather than taking the typical custom_section path for wasm.

The wasm-ld appears to have a bunch of limitations. Only one static with the `link_section` in a crate or else you hit the fatal error in the link above "only one .init_array section fragment supported". They do not get merged.

You can still call multiple constructors by setting it to an array.

```
unsafe extern "C" fn ctor() {
    println!("foo");
}
#[used]
#[link_section = ".init_array"]
static FOO: [unsafe extern "C" fn(); 2] = [ctor, ctor];
```

Another issue appears to be that if crate *A* depends on crate *B*, but *A* doesn't call any symbols from *B* and *B* doesn't `#[export_name = ...]` any symbols, then crate *B*'s constructor will not be called.  The workaround to this is to provide an exported symbol in crate *B*.
2024-07-19 03:27:46 -05:00
Trevor Gross
5686720a57 Update the binary_asm_label documentation
Disable a test that now only passes on x86 and make the link point to
the new (open) LLVM bug.
2024-07-19 01:21:15 -05:00
Nicholas Nethercote
1dd566a6d0 Overhaul comments in collect_tokens_trailing_token.
Adding details, clarifying lots of little things, etc. In particular,
the commit adds details of an example. I find this very helpful, because
it's taken me a long time to understand how this code works.
2024-07-19 15:25:55 +10:00
Nicholas Nethercote
ca6649516f Make Parser::num_bump_calls 0-indexed.
Currently in `collect_tokens_trailing_token`, `start_pos` and `end_pos`
are 1-indexed by `replace_ranges` is 0-indexed, which is really
confusing. Making them both 0-indexed makes debugging much easier.
2024-07-19 15:25:55 +10:00
Nicholas Nethercote
f9c7ca70cb Move inner_attr code downwards.
This puts it just before the `replace_ranges` initialization, which
makes sense because the two variables are closely related.
2024-07-19 15:25:54 +10:00
Nicholas Nethercote
1f67cf9e63 Remove final_attrs local variable.
It's no shorter than `ret.attrs()`, and `ret.attrs()` is used multiple
times earlier in the function.
2024-07-19 15:25:54 +10:00
Nicholas Nethercote
757f73f506 Simplify CaptureState::inner_attr_ranges.
The `Option`s within the `ReplaceRange`s within the hashmap are always
`None`. This PR omits them and inserts them when they are extracted from
the hashmap.
2024-07-19 15:25:54 +10:00
Kai Luo
ec805d17eb Revert format change 2024-07-19 13:02:51 +08:00
Kai Luo
c72df9ddf9 AIX uses .a as dylib's suffix 2024-07-19 12:40:09 +08:00
bors
3d68afc9e8 Auto merge of #127936 - matthiaskrgr:rollup-ci0eg7k, r=tgross35
Rollup of 8 pull requests

Successful merges:

 - #127418 (Wrap too long type name)
 - #127594 (Fuchsia status code match arm)
 - #127835 (Fix ICE in suggestion caused by `⩵` being recovered as `==`)
 - #127858 (match lowering: Rename `MatchPair` to `MatchPairTree`)
 - #127871 (Mention that type parameters are used recursively on bivariance error)
 - #127913 (remove `debug-logging` default from tools profile)
 - #127925 (Remove tag field from `Relation`s)
 - #127929 (Use more accurate span for `addr_of!` suggestion)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 02:05:32 +00: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
11688370dd
Rollup merge of #127925 - compiler-errors:tag, r=lcnr
Remove tag field from `Relation`s

Can just use the relation name w/ `std::any::type_name`. Also changes some printing to use instrument. Also changes some instrument levels to `trace` since I expect relations are somewhat hot, so having them print on debug is probably noisy.

r? lcnr
2024-07-18 23:05:24 +02:00
Matthias Krüger
f4a9f7f524
Rollup merge of #127913 - onur-ozkan:broken-defaults, r=Kobzol
remove `debug-logging` default from tools profile

`debug-logging` conflicts with `download-rustc` option, and doesn't really make sense to enable it for a profile that is used for tool development.
2024-07-18 23:05:23 +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
4d5ba0d2c7
Rollup merge of #127858 - Zalathar:pair-tree, r=Nadrieril
match lowering: Rename `MatchPair` to `MatchPairTree`

In #120904, `MatchPair` became able to store other match pairs as children, forming a tree. That has made the old name confusing, so this patch renames the type to `MatchPairTree`.

This PR also includes a patch renaming the `test` method to `pick_test_for_match_pair`, since it would conflict with the main change.

r? `@Nadrieril`
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
Oneirical
730313227f rewrite link-path-order to rmake 2024-07-18 16:27:34 -04: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
Guillaume Gomez
c820a2392c Add test for size of items in the items list 2024-07-18 20:48:20 +02:00
Guillaume Gomez
fed059270a Wrap too long item name and improve the item list display a bit 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
Michael Goulet
8dbb63a585 Remove tag field from relations 2024-07-18 14:34:05 -04: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
bors
5affbb1715 Auto merge of #127924 - matthiaskrgr:rollup-1gn6afv, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #124881 (Use ThreadId instead of TLS-address in `ReentrantLock`)
 - #127656 (make pub_use_of_private_extern_crate show up in cargo's future breakage reports)
 - #127748 (Use Option's discriminant as its size hint)
 - #127854 (Add internal lint for detecting non-glob imports of `rustc_type_ir::inherent`)
 - #127908 (Update extern linking documentation)
 - #127919 (Allow a git command for getting the current branch in bootstrap to fail)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-18 18:12:47 +00:00