Commit Graph

268453 Commits

Author SHA1 Message Date
Jubilee Young
187c8b0ce9 library: Stabilize const_replace
Depends on stabilizing `const_ptr_write`.

Const-stabilizes:
- `core::mem::replace`
- `core::ptr::replace`
2024-10-12 00:02:38 -07:00
Jubilee Young
ddc367ded7 library: Stabilize const_ptr_write
Const-stabilizes:
- `write`
- `write_bytes`
- `write_unaligned`

In the following paths:
- `core::ptr`
- `core::ptr::NonNull`
- pointer `<*mut T>`

Const-stabilizes the internal `core::intrinsics`:
- `write_bytes`
- `write_via_move`
2024-10-12 00:02:36 -07:00
Jubilee Young
9a523001e3 library: Stabilize const_intrinsic_forget
This is an implicit requirement of stabilizing `const_ptr_write`.

Const-stabilizes the internal `core::intrinsics`:
- `forget`
2024-10-12 00:02:09 -07:00
onur-ozkan
4454fa998c add new CI step: "setup upstream remote"
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-10-12 08:58:39 +03:00
onur-ozkan
33ac202904 force "HEAD" for non-CI and git_upstream_merge_base for CI environment
When rust-lang/rust is configured as remote, some of the git
logic (for tracking changed files) that uses get_closest_merge_commit
starts to produce annoying results as the upstream branch becomes outdated
quickly (since it isn't updated with git pull). We can rely on HEAD for
non-CI environments as we specifically treat bors commits as merge commits,
which also exist on upstream. As for CI environments, we should use
`git_upstream_merge_base` to correctly track modified files as bors commits
may be in `HEAD` but not yet on the upstream remote.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-10-12 07:45:24 +03:00
Trevor Gross
5e477c9107
Rollup merge of #131576 - Zalathar:tests-tests, r=jieyouxu
Flatten redundant test module `run_make_support::diff::tests::tests`

This module is already named `tests`, and is already gated by `#[cfg(test)]`, so there's no need for it to also contain `mod tests`.

r? jieyouxu
2024-10-11 23:57:48 -04:00
Trevor Gross
1f31925345
Rollup merge of #131565 - Urgau:non_local_def-rm-deprecate, r=compiler-errors
Remove deprecation note in the `non_local_definitions` lint

This PR removes the edition deprecation note emitted by the `non_local_definitions` lint.

Specifically this part:

```
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
```

because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.

`@rustbot` label +L-non_local_definitions
2024-10-11 23:57:47 -04:00
Trevor Gross
fcbf4ac6f9
Rollup merge of #131546 - surechen:fix_129833, r=jieyouxu
Make unused_parens's suggestion considering expr's attributes.

For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-11 23:57:46 -04:00
Trevor Gross
9e72070f77
Rollup merge of #131310 - taiki-e:msp430-clobber-abi, r=Amanieu
Support clobber_abi in MSP430 inline assembly

This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.

Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf)

cc ``@cr1901``

r? ``@Amanieu``

``@rustbot`` label +O-msp430
2024-10-11 23:57:46 -04:00
Trevor Gross
3e16b77465
Rollup merge of #131289 - RalfJung:duration_consts_float, r=tgross35
stabilize duration_consts_float

Waiting for FCP in https://github.com/rust-lang/rust/issues/72440 to pass.

`as_millis_f32` and `as_millis_f64` are not stable at all yet, so I moved their const-stability together with their regular stability (tracked at https://github.com/rust-lang/rust/issues/122451).

Fixes https://github.com/rust-lang/rust/issues/72440
2024-10-11 23:57:45 -04:00
Trevor Gross
02cf62c596
Rollup merge of #130962 - nyurik:opts-libs, r=cuviper
Migrate lib's `&Option<T>` into `Option<&T>`

Trying out my new lint https://github.com/rust-lang/rust-clippy/pull/13336 - according to the [video](https://www.youtube.com/watch?v=6c7pZYP_iIE), this could lead to some performance and memory optimizations.

Basic thoughts expressed in the video that seem to make sense:
* `&Option<T>` in an API breaks encapsulation:
  * caller must own T and move it into an Option to call with it
  * if returned, the owner must store it as Option<T> internally in order to return it
* Performance is subject to compiler optimization, but at the basics, `&Option<T>` points to memory that has `presence` flag + value, whereas `Option<&T>` by specification is always optimized to a single pointer.
2024-10-11 23:57:44 -04:00
Trevor Gross
3f9aa50b70
Rollup merge of #124874 - jedbrown:float-mul-add-fast, r=saethlin
intrinsics fmuladdf{32,64}: expose llvm.fmuladd.* semantics

Add intrinsics `fmuladd{f32,f64}`. This computes `(a * b) + c`, to be fused if the code generator determines that (i) the target instruction set has support for a fused operation, and (ii) that the fused operation is more efficient than the equivalent, separate pair of `mul` and `add` instructions.

https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic

The codegen_cranelift uses the `fma` function from libc, which is a correct implementation, but without the desired performance semantic. I think this requires an update to cranelift to expose a suitable instruction in its IR.

I have not tested with codegen_gcc, but it should behave the same way (using `fma` from libc).

---
This topic has been discussed a few times on Zulip and was suggested, for example, by `@workingjubilee` in [Effect of fma disabled](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Effect.20of.20fma.20disabled/near/274179331).
2024-10-11 23:57:44 -04:00
许杰友 Jieyou Xu (Joe)
1fe079bd62 Remap path refix in the panic message
Otherwise `error-pattern` on the test run stderr can incorrectly match
if e.g. the paths in panic backtrace has a matching substring (like if
we look for `bar` in the error pattern but username is `baron`).
2024-10-12 09:41:42 +08:00
surechen
1e8d6d1ec3 Make unused_parens's suggestion considering expr's attributes
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-12 09:32:25 +08:00
Zalathar
f4376c426b Avoid cross-file glob import 2024-10-12 11:59:57 +11:00
Zalathar
395b0787d4 Flatten redundant test module run_make_support::diff::tests::tests 2024-10-12 11:54:33 +11:00
Jubilee Young
10721909f2 compiler: Wire {TyAnd,}Layout into rustc_abi
This finally unites TyAndLayout, Layout, and LayoutS into the same crate,
as one might imagine they would be placed. No functional changes.
2024-10-11 17:41:52 -07:00
Jubilee Young
255bdd2f24 compiler: Empty out rustc_target::abi 2024-10-11 17:41:52 -07:00
Jubilee Young
559de74562 compiler: Move impl of ToJson for abi::Endian 2024-10-11 17:41:52 -07:00
bors
fb20e4d3b9 Auto merge of #131573 - tgross35:rollup-r7l182a, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #130078 (rustdoc-json: change item ID's repr from a string to an int)
 - #131065 (Port sort-research-rs test suite to Rust stdlib tests)
 - #131109 (Stabilize `debug_more_non_exhaustive`)
 - #131287 (stabilize const_result)
 - #131463 (Stabilise `const_char_encode_utf8`.)
 - #131543 (coverage: Remove code related to LLVM 17)
 - #131552 (RustWrapper: adapt for rename of Intrinsic::getDeclaration)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-11 23:57:42 +00:00
Trevor Gross
6f76d6e1a3
Rollup merge of #131552 - durin42:llvm-20-getOrInsertDeclaration, r=cuviper
RustWrapper: adapt for rename of Intrinsic::getDeclaration

llvm/llvm-project@fa789dffb1 renamed getDeclaration to getOrInsertDeclaration.

`@rustbot` label: +llvm-main
2024-10-11 16:53:50 -05:00
Trevor Gross
2c385ba329
Rollup merge of #131543 - Zalathar:goodbye-llvm-17, r=petrochenkov
coverage: Remove code related to LLVM 17

In-tree LLVM is 19, and the minimum external LLVM was increased to 18 in #130487.
2024-10-11 16:53:49 -05:00
Trevor Gross
8ea41b903f
Rollup merge of #131463 - bjoernager:const-char-encode-utf8, r=RalfJung
Stabilise `const_char_encode_utf8`.

Closes: #130512

This PR stabilises the `const_char_encode_utf8` feature gate (i.e. support for `char::encode_utf8` in const scenarios).

Note that the linked tracking issue is currently awaiting FCP.
2024-10-11 16:53:49 -05:00
Trevor Gross
622fc5e0f3
Rollup merge of #131287 - RalfJung:const_result, r=tgross35
stabilize const_result

Waiting for FCP to complete in https://github.com/rust-lang/rust/issues/82814

Fixes #82814
2024-10-11 16:53:48 -05:00
Trevor Gross
8797cfed68
Rollup merge of #131109 - tgross35:stabilize-debug_more_non_exhaustive, r=joboet
Stabilize `debug_more_non_exhaustive`

Fixes: https://github.com/rust-lang/rust/issues/127942
2024-10-11 16:53:47 -05:00
Trevor Gross
f241d0a230
Rollup merge of #131065 - Voultapher:port-sort-test-suite, r=thomcc
Port sort-research-rs test suite to Rust stdlib tests

This PR is a followup to https://github.com/rust-lang/rust/pull/124032. It replaces the tests that test the various sort functions in the standard library with a test-suite developed as part of https://github.com/Voultapher/sort-research-rs. The current tests suffer a couple of problems:

- They don't cover important real world patterns that the implementations take advantage of and execute special code for.
- The input lengths tested miss out on code paths. For example, important safety property tests never reach the quicksort part of the implementation.
- The miri side is often limited to `len <= 20` which means it very thoroughly tests the insertion sort, which accounts for 19 out of 1.5k LoC.
- They are split into to core and alloc, causing code duplication and uneven coverage.
- ~~The randomness is tied to a caller location, wasting the space exploration capabilities of randomized testing.~~ The randomness is not repeatable, as it relies on `std:#️⃣:RandomState::new().build_hasher()`.

Most of these issues existed before https://github.com/rust-lang/rust/pull/124032, but they are intensified by it. One thing that is new and requires additional testing, is that the new sort implementations specialize based on type properties. For example `Freeze` and non `Freeze` execute different code paths.

Effectively there are three dimensions that matter:

- Input type
- Input length
- Input pattern

The ported test-suite tests various properties along all three dimensions, greatly improving test coverage. It side-steps the miri issue by preferring sampled approaches. For example the test that checks if after a panic the set of elements is still the original one, doesn't do so for every single possible panic opportunity but rather it picks one at random, and performs this test across a range of input length, which varies the panic point across them. This allows regular execution to easily test inputs of length 10k, and miri execution up to 100 which covers significantly more code. The randomness used is tied to a fixed - but random per process execution - seed. This allows for fully repeatable tests and fuzzer like exploration across multiple runs.

Structure wise, the tests are previously found in the core integration tests for `sort_unstable` and alloc unit tests for `sort`. The new test-suite was developed to be a purely black-box approach, which makes integration testing the better place, because it can't accidentally rely on internal access. Because unwinding support is required the tests can't be in core, even if the implementation is, so they are now part of the alloc integration tests. Are there architectures that can only build and test core and not alloc? If so, do such platforms require sort testing? For what it's worth the current implementation state passes miri `--target mips64-unknown-linux-gnuabi64` which is big endian.

The test-suite also contains tests for properties that were and are given by the current and previous implementations, and likely relied upon by users but weren't tested. For example `self_cmp` tests that the two parameters `a` and `b` passed into the comparison function are never references to the same object, which if the user is sorting for example a `&mut [Mutex<i32>]` could lead to a deadlock.

Instead of using the hashed caller location as rand seed, it uses seconds since unix epoch / 10, which given timestamps in the CI should be reasonably easy to reproduce, but also allows fuzzer like space exploration.

---

Test run-time changes:

Setup:

```
Linux 6.10
rustc 1.83.0-nightly (f79a912d9 2024-09-18)
AMD Ryzen 9 5900X 12-Core Processor (Zen 3 micro-architecture)
CPU boost enabled.
```

master: e9df22f

Before core integration tests:

```
$ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/coretests-219cbd0308a49e2f
  Time (mean ± σ):     869.6 ms ±  21.1 ms    [User: 1327.6 ms, System: 95.1 ms]
  Range (min … max):   845.4 ms … 917.0 ms    10 runs

# MIRIFLAGS="-Zmiri-disable-isolation" to get real time
$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/core
  finished in 738.44s
```

After core integration tests:

```
$ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/coretests-219cbd0308a49e2f
  Time (mean ± σ):     865.1 ms ±  14.7 ms    [User: 1283.5 ms, System: 88.4 ms]
  Range (min … max):   836.2 ms … 885.7 ms    10 runs

$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/core
  finished in 752.35s
```

Before alloc unit tests:

```
LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloc-19c15e6e8565aa54
  Time (mean ± σ):     295.0 ms ±   9.9 ms    [User: 719.6 ms, System: 35.3 ms]
  Range (min … max):   284.9 ms … 319.3 ms    10 runs

$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc
  finished in 322.75s
```

After alloc unit tests:

```
LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloc-19c15e6e8565aa54
  Time (mean ± σ):      97.4 ms ±   4.1 ms    [User: 297.7 ms, System: 28.6 ms]
  Range (min … max):    92.3 ms … 109.2 ms    27 runs

$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc
  finished in 309.18s
```

Before alloc integration tests:

```
$ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloctests-439e7300c61a8046
  Time (mean ± σ):     103.2 ms ±   1.7 ms    [User: 135.7 ms, System: 39.4 ms]
  Range (min … max):    99.7 ms … 107.3 ms    28 runs

$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc
  finished in 231.35s
```

After alloc integration tests:

```
$ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloctests-439e7300c61a8046
  Time (mean ± σ):     379.8 ms ±   4.7 ms    [User: 4620.5 ms, System: 1157.2 ms]
  Range (min … max):   373.6 ms … 386.9 ms    10 runs

$ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc
  finished in 449.24s
```

In my opinion the results don't change iterative library development or CI execution in meaningful ways. For example currently the library doc-tests take ~66s and incremental compilation takes 10+ seconds. However I only have limited knowledge of the various local development workflows that exist, and might be missing one that is significantly impacted by this change.
2024-10-11 16:53:47 -05:00
Trevor Gross
05c0591321
Rollup merge of #130078 - its-the-shrimp:rustdoc-types-compress-ids, r=aDotInTheVoid
rustdoc-json: change item ID's repr from a string to an int

Following [this discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Optimizing.20the.20.60Id.60.20type.20in.20.60rustdoc-types.60), I've changed the repr of `rustdoc_json_types::Id` from a String to a u32, by adding a `clean::ItemId` interner to `JsonRenderer`

r? ``@aDotInTheVoid``
2024-10-11 16:53:46 -05:00
Jed Brown
0d8a978e8a intrinsics.fmuladdf{16,32,64,128}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.

https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic

MIRI support is included for f32 and f64.

The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.

I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
2024-10-11 15:32:56 -06:00
bors
1bc403daad Auto merge of #131531 - onur-ozkan:move-dummy-commit, r=Kobzol
move dummy commit logic into x86_64-gnu-llvm-18

Doing the dummy commit logic in a runner that uses CI-LLVM breaks in merge CI. This should be properly fixed by https://github.com/rust-lang/rust/pull/131358 (see the [actual problem](https://github.com/rust-lang/rust/pull/131448#issuecomment-2406516261)). Since we can also fix it by moving the dummy commit into the runner where we use in-tree LLVM, so why not do that as well?
2024-10-11 21:29:26 +00:00
Urgau
77b3065ed2 Remove deprecation note in the non_local_definitions warning 2024-10-11 21:21:32 +02:00
Manuel Drehwald
7c37d2db98 Add pretty, ui, and feature-gate tests for the enzyme/autodiff frontend 2024-10-11 20:38:43 +02:00
Manuel Drehwald
624c071b99 Single commit implementing the enzyme/autodiff frontend
Co-authored-by: Lorenz Schmidt <bytesnake@mailbox.org>
2024-10-11 19:13:31 +02:00
Josh Stone
734481cbdc Bump to 1.84 2024-10-11 09:55:11 -07:00
Ralf Jung
92f65684a8 stabilize const_result 2024-10-11 18:34:28 +02:00
Augie Fackler
19345d5c6e RustWrapper: adapt for rename of Intrinsic::getDeclaration
llvm/llvm-project@fa789dffb1 renamed
getDeclaration to getOrInsertDeclaration.

@rustbot label: +llvm-main
2024-10-11 12:29:49 -04:00
bors
01e2fff90c Auto merge of #131547 - matthiaskrgr:rollup-ui4p744, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #129079 (Create `_imp__` symbols also when doing ThinLTO)
 - #131208 (ABI: Pass aggregates by value on AIX)
 - #131394 (fix(rustdoc): add space between struct fields and their descriptions)
 - #131519 (Use Default visibility for rustc-generated C symbol declarations)
 - #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct)
 - #131542 (next-solver: remove outdated FIXMEs)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-11 16:27:23 +00:00
Ralf Jung
181e667626 stabilize duration_consts_float 2024-10-11 18:23:30 +02:00
VulnBandit
9a2772e1c2 Don't assume traits used as type are trait objs 2024-10-11 17:36:04 +02:00
Michael Goulet
d6391d5d4d Note what qualifier 2024-10-11 11:30:08 -04:00
Michael Goulet
c085071631 Remove unadorned 2024-10-11 11:30:08 -04:00
Matthias Krüger
b18e1aa612
Rollup merge of #131542 - lcnr:new-solver-fixmes, r=compiler-errors
next-solver: remove outdated FIXMEs

r? `@compiler-errors`
2024-10-11 15:36:53 +02:00
Matthias Krüger
7f79c1e640
Rollup merge of #131541 - Zalathar:aux-props, r=jieyouxu
compiletest: Extract auxiliary-crate properties to their own module/struct

This moves the values of the 4 different `aux-*` directives into their own sub-struct. That struct, along with its directive-parsing code, can then be shared by both `TestProps` and `EarlyProps`.

The final patch also fixes an oversight in up-to-date checking, by including *all* auxiliary crates in the timestamp, not just ordinary `aux-build` ones.
2024-10-11 15:36:53 +02:00
Matthias Krüger
33b1264540
Rollup merge of #131519 - davidlattimore:intrinsics-default-vis, r=Urgau
Use Default visibility for rustc-generated C symbol declarations

Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail.

This is based on https://github.com/rust-lang/rust/pull/123994.

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

When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility.

Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
2024-10-11 15:36:52 +02:00
Matthias Krüger
103c71686a
Rollup merge of #131394 - ismailarilik:fix/rustdoc/add-space-between-struct-fields-and-their-descriptions, r=GuillaumeGomez
fix(rustdoc): add space between struct fields and their descriptions

Stolen from #128541.
Fixes #128260.

<table>
  <thead>
    <tr>
      <th scope="col">Before</th>
      <th scope="col">After</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td scope="row">
        <img
          src="https://github.com/user-attachments/assets/b1d3cb47-77c9-4897-a5d2-2192b11cb8a3"
        />
      </td>
      <td>
        <img
          src="https://github.com/user-attachments/assets/0b104672-d2be-49f4-ac9b-3506526fe2f1"
        />
      </td>
    </tr>
  </tbody>
</table>

<table>
  <thead>
    <tr>
      <th scope="col">Before</th>
      <th scope="col">After</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td scope="row">
        <img
          src="https://github.com/user-attachments/assets/650c3e74-a067-492a-9ba3-557f9214f875"
        />
      </td>
      <td>
        <img
          src="https://github.com/user-attachments/assets/413ef9b0-8fca-4e16-978a-7b88d05299dc"
        />
      </td>
    </tr>
  </tbody>
</table>

Unlike original PR, I didn't add space between field headers; I put it between headers and descriptions. So if there are only headers, the space is not changed. Otherwise, I put a space like the space between paragraphs (.75em) which makes sense for me but feel free to adjust it or ask me to do so.

r? `@GuillaumeGomez`
2024-10-11 15:36:52 +02:00
Matthias Krüger
fc81a7c1d5
Rollup merge of #131208 - mustartt:aix-call-abi, r=davidtwco
ABI: Pass aggregates by value on AIX

On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.

313ad85dfa/clang/lib/CodeGen/Targets/PPC.cpp (L216)

Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
2024-10-11 15:36:51 +02:00
Matthias Krüger
7c79621462
Rollup merge of #129079 - Zoxc:thinlto_imp_symbols, r=wesleywiser
Create `_imp__` symbols also when doing ThinLTO

When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.

This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.

This is an workaround for https://github.com/rust-lang/rust/issues/81408.

cc `@lqd`
2024-10-11 15:36:51 +02:00
bors
f4966590d8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
onur-ozkan
b72dbd56ca move dummy commit logic into x86_64-gnu-llvm-18
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-10-11 15:30:51 +03:00
Zalathar
9357277de7 coverage: Remove code related to LLVM 17 2024-10-11 21:44:36 +11:00
bors
2eda6a4e6e Auto merge of #3964 - RalfJung:write-during-2phase, r=RalfJung
simplify Tree Borrows write-during-2phase example
2024-10-11 10:41:15 +00:00