Commit Graph

269117 Commits

Author SHA1 Message Date
Matthias Krüger
7e1dbaec13
Rollup merge of #132002 - RalfJung:abi-compat-option-like, r=compiler-errors
abi/compatibility: also test Option-like types

Adds tests for the decision [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599).

Cc ``@workingjubilee``
2024-10-23 06:51:24 +02:00
Matthias Krüger
38eaf608eb
Rollup merge of #131707 - clarfonthey:constify-core-tests, r=thomcc
Run most `core::num` tests in const context too

This adds some infrastructure for something I was going to use in #131566, but it felt worthwhile enough on its own to merge/discuss separately.

Essentially, right now we tend to rely on UI tests to ensure that things work in const context, rather than just using library tests. This uses a few simple macro tricks to make it *relatively* painless to execute tests in both runtime and compile-time context. And this only applies to the numeric tests, and not anything else.

Recommended to review without whitespace in the diff.

cc `@RalfJung`
2024-10-23 06:51:23 +02:00
bors
b13176595d Auto merge of #131929 - LaihoE:replace_default_capacity, r=joboet
better default capacity for str::replace

Adds smarter capacity for str::replace in cases where we know that the output will be at least as long as the original string.
2024-10-23 01:03:48 +00:00
bors
8bf64f106a Auto merge of #131871 - RalfJung:x86-32-float, r=workingjubilee
x86-32 float return for 'Rust' ABI: treat all float types consistently

This helps with https://github.com/rust-lang/rust/issues/131819: for our own ABI on x86-32, we want to *never* use the float registers. The previous logic only considered F32 and F64, but skipped F16 and F128. So I made the logic just apply to all float types.

try-job: i686-gnu
try-job: i686-gnu-nopt
2024-10-22 22:36:59 +00:00
Laiho
c8391802af better default capacity for str::replace 2024-10-22 19:53:33 +03:00
bors
86d69c705a Auto merge of #132035 - matthiaskrgr:rollup-ty1e4q0, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
 - #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
 - #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
 - #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
 - #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
 - #132006 (don't stage-off to previous compiler when CI rustc is available)
 - #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
 - #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 14:16:37 +00:00
Matthias Krüger
6db5f332af
Rollup merge of #132033 - Zalathar:directive-line, r=jieyouxu
compiletest: Make `line_directive` return a `DirectiveLine`

This reduces the need to juggle raw tuples, and opens up the possibility of moving more parts of directive parsing into `line_directive`.

In order to make the main change possible, this PR also (partly) separates the debugger-command parsing from the main directive parser. That cleanup removes support for `[rev]` in debugger commands, which is not used by any tests.
2024-10-22 15:28:52 +02:00
Matthias Krüger
f5aa456646
Rollup merge of #132022 - Zalathar:dominator-order, r=tmiasko
Move `cmp_in_dominator_order` out of graph dominator computation

Dominator-order information is only needed for coverage graphs, and is easy enough to collect by just traversing the graph again.

This avoids wasted work when computing graph dominators for any other purpose.
2024-10-22 15:28:50 +02:00
Matthias Krüger
56eae720bd
Rollup merge of #132006 - onur-ozkan:131947, r=jieyouxu
don't stage-off to previous compiler when CI rustc is available

Resolves the 4th item in [Tracking Issue for download-rustc improvements](https://github.com/rust-lang/rust/issues/131744).
2024-10-22 15:28:47 +02:00
Matthias Krüger
83085b99c2
Rollup merge of #131732 - m4tx:fix-82824, r=davidtwco
Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES

This fixes #82824.
2024-10-22 15:28:45 +02:00
Matthias Krüger
cbb85f1bd5
Rollup merge of #131731 - lucarlig:master, r=onur-ozkan
add `TestFloatParse` to `tools.rs` for bootstrap

add TestFloatParse to tools for bootstrap, I am not sure this is what the issue https://github.com/rust-lang/rust/issues/128012 discussion wants.

try-job: aarch64-apple
2024-10-22 15:28:43 +02:00
Matthias Krüger
457087ed29
Rollup merge of #131549 - compiler-errors:try-in-sync, r=spastorino
Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function

It's confusing to `?` a future of a result in a sync function. We have a suggestion to `.await` it if we're in an async function, but not a sync function. Note that this is the case for sync functions, at least.

Let's be a bit more vague about a fix, since it's somewhat context dependent. For example, you could block on it, or you could make your function asynchronous. 🤷
2024-10-22 15:28:41 +02:00
Matthias Krüger
3f15d296f4
Rollup merge of #131049 - compiler-errors:more-validation, r=spastorino
Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`

For the `Existential*` ones, we have to do some adjustment to the args list to deal with the missing `Self` type, so we introduce a `debug_assert_existential_args_compatible` function to the interner as well.
2024-10-22 15:28:38 +02:00
Matthias Krüger
4d378f26a9
Rollup merge of #125205 - ChrisDenton:verbatim-include, r=jieyouxu
Fixup Windows verbatim paths when used with the `include!` macro

On Windows, the following code can fail if the `OUT_DIR` environment variable is a [verbatim path](https://doc.rust-lang.org/std/path/enum.Prefix.html) (i.e. begins with `\\?\`):

```rust
include!(concat!(env!("OUT_DIR"), "/src/repro.rs"));
```

This is because verbatim paths treat `/` literally, as if it were just another character in the file name.

The good news is that the standard library already has code to fix this. We can simply use `components` to normalize the path so it works as intended.
2024-10-22 15:28:35 +02:00
Ralf Jung
09068192f8 adjust asm test 2024-10-22 12:21:00 +01:00
bors
bca5fdebe0 Auto merge of #131321 - RalfJung:feature-activation, r=nnethercote
terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)

Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](f25e5abea2/compiler/rustc_passes/messages.ftl (L297-L301))), which aligns better with what "declaring" usually means. To make things worse, the functions  `tcx.features().active(...)` and  `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]`  exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.

So really, our terminology is just a mess.

I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for  `#[feature(name)]`. This PR implements that.
2024-10-22 11:02:35 +00:00
Zalathar
997b7a6ed0 Make line_directive return a DirectiveLine
This reduces the need to juggle raw tuples, and opens up the possibility of
moving more parts of directive parsing into `line_directive`.
2024-10-22 21:47:51 +11:00
Zalathar
c4016ea455 Rename some fields of DirectiveLine 2024-10-22 21:47:51 +11:00
Zalathar
1467deea64 Stop using line_directive in runtest::debugger
This also removes unused support for `[rev]` in debugger commands, and makes
breakpoint detection slightly more sensible.
2024-10-22 21:29:08 +11:00
Zalathar
7f4dd9bb81 Move cmp_in_dominator_order out of graph dominator computation
Dominator-order information is only needed for coverage graphs, and is easy
enough to collect by just traversing the graph again.

This avoids wasted work when computing graph dominators for any other purpose.
2024-10-22 20:44:09 +11:00
bors
916e9ced40 Auto merge of #132030 - matthiaskrgr:rollup-1g6quh0, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 - #131918 (coverage: Make counter creation handle node/edge counters more uniformly)
 - #132021 (nuttx.md: typo)
 - #132029 (Subtree update of `rust-analyzer`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 08:34:18 +00:00
Matthias Krüger
6e7fcb2a60
Rollup merge of #132029 - lnicola:sync-from-ra, r=lnicola
Subtree update of `rust-analyzer`

r? `@ghost`
2024-10-22 10:08:47 +02:00
Matthias Krüger
31a9d741ec
Rollup merge of #132021 - tshepang:patch-2, r=workingjubilee
nuttx.md: typo
2024-10-22 10:08:46 +02:00
Matthias Krüger
703b042be8
Rollup merge of #131918 - Zalathar:counters, r=nnethercote
coverage: Make counter creation handle node/edge counters more uniformly

Similar to #130380, this is another round of small improvements informed by my ongoing attempts to overhaul coverage counter creation.

One of the big benefits is getting rid of the awkward special-case that would sometimes attach an edge counter to a node instead. That was needed by the code that chooses which out-edge should be given a counter expression, but we can avoid that by making the corresponding check a little smarter.

I've also renamed several things to be simpler and more consistent, which should help with future changes.
2024-10-22 10:08:46 +02:00
bors
ca51c1e72c Auto merge of #18364 - lnicola:sync-from-rust, r=lnicola
minor: sync from downstream
2024-10-22 07:21:22 +00:00
Laurențiu Nicola
efc2ba2d90 Replace some LayoutError variants with the rustc_abi errors 2024-10-22 10:19:25 +03:00
Laurențiu Nicola
420b665c60 Bump rustc crates 2024-10-22 10:12:46 +03:00
Laurențiu Nicola
5d540f4cc9 Merge from rust-lang/rust 2024-10-22 10:12:22 +03:00
Laurențiu Nicola
5038ee7282 Preparing for merge from rust-lang/rust 2024-10-22 10:12:20 +03:00
Ralf Jung
1381773e01 make some rustc_feature internals private, and ensure invariants with debug assertions 2024-10-22 07:37:55 +01:00
Ralf Jung
46ce5cbf33 terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it) 2024-10-22 07:37:54 +01:00
bors
f225713007 Auto merge of #132020 - workingjubilee:rollup-a8iehqg, r=workingjubilee
Rollup of 6 pull requests

Successful merges:

 - #130432 (rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972))
 - #131697 (`rt::Argument`: elide lifetimes)
 - #131807 (Always specify `llvm_abiname` for RISC-V targets)
 - #131954 (shave 150ms off bootstrap)
 - #132015 (Move const trait tests from `ui/rfcs/rfc-2632-const-trait-impl` to `ui/traits/const-traits`)
 - #132017 (Update triagebot.toml)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 05:49:18 +00:00
Tshepang Mbambo
3952d493a7
nuttx.md: typo 2024-10-22 05:36:39 +02:00
Jubilee
0e307bb90e
Rollup merge of #132017 - celinval:smir-update-reviewerss, r=scottmcm
Update triagebot.toml

Update the list of reviewers after updating the team here: https://github.com/rust-lang/team/pull/1555
2024-10-21 20:32:02 -07:00
Jubilee
1ea4eabb81
Rollup merge of #132015 - compiler-errors:move-const-trait-tests, r=fee1-dead
Move const trait tests from `ui/rfcs/rfc-2632-const-trait-impl` to `ui/traits/const-traits`

I found the old test directory to be somewhat long to name, and I don't think it's necessary to put an experimental implementation's tests under an rfc which is closed.

r? fee1-dead

Breaking this out of #131985 so that PR doesn't touch 300 files.
2024-10-21 20:32:02 -07:00
Jubilee
aba227b3a9
Rollup merge of #131954 - the8472:bootstrap-parallel-git, r=Kobzol
shave 150ms off bootstrap

This starts `git` commands inside `GitInfo`and the submodule updates in parallel. Git should already perform internal locking in cases where it needs to serialize a modification.

```
OLD
Benchmark #1: ./x check core
  Time (mean ± σ):     608.7 ms ±   4.4 ms    [User: 368.3 ms, System: 455.1 ms]
  Range (min … max):   602.3 ms … 618.8 ms    10 runs

NEW
Benchmark #1: ./x check core
  Time (mean ± σ):     462.8 ms ±   2.6 ms    [User: 350.2 ms, System: 485.1 ms]
  Range (min … max):   457.5 ms … 465.6 ms    10 runs
```

This should help with the rust-analyzer setup which issues many individual `./x check` calls. There's more that could be done but these were the lowest-hanging fruits that I saw.
2024-10-21 20:32:02 -07:00
Jubilee
1b24c6fc14
Rollup merge of #131807 - beetrees:riscv-target-abi, r=workingjubilee
Always specify `llvm_abiname` for RISC-V targets

For RISC-V targets, when `llvm_abiname` is not specified LLVM will infer the ABI from the target features, causing #116344 to occur. This PR adds the correct `llvm_abiname` to all RISC-V targets where it is missing (which are all soft-float targets), and adds a test to prevent future RISC-V targets from accidentally omitting `llvm_abiname`. The only affect of this PR is that `-Ctarget-feature=+f` (or similar) will no longer affect the ABI on the modified targets.

<!-- homu-ignore:start -->
r? `@RalfJung`
<!--- homu-ignore:end -->
2024-10-21 20:32:01 -07:00
Jubilee
763fbf8a90
Rollup merge of #131697 - ShE3py:rt-arg-lifetimes, r=Amanieu
`rt::Argument`: elide lifetimes

`@rustbot` label +C-cleanup
2024-10-21 20:32:01 -07:00
Jubilee
fe2cbbd2d5
Rollup merge of #130432 - azhogin:azhogin/regparm, r=workingjubilee,pnkfelix
rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972)

Command line flag `-Zregparm=<N>` for X86 (32-bit) for rust-for-linux: https://github.com/rust-lang/rust/issues/116972
Implemented in the similar way as fastcall/vectorcall support (args are marked InReg if fit).
2024-10-21 20:32:00 -07:00
bors
1de57a5ce9 Auto merge of #129935 - RalfJung:unsupported_calling_conventions, r=compiler-errors
make unsupported_calling_conventions a hard error

This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) even when the lint was originally added.

This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.)

Fixes https://github.com/rust-lang/rust/pull/87678
2024-10-22 03:24:40 +00:00
Michael Goulet
e91267f3f0 Move tests 2024-10-22 00:03:09 +00:00
bors
814df6e50e Auto merge of #131840 - compiler-errors:impossible-maybe, r=lcnr
Dont consider predicates that may hold as impossible in `is_impossible_associated_item`

Use infer vars to account for ambiguities when considering if methods are impossible to instantiate for a given self type. Also while we're at it, let's use the new trait solver instead of `evaluate` since this is used in rustdoc.

r? lcnr
Fixes #131839
2024-10-21 22:58:44 +00:00
bors
4392847410 Auto merge of #131570 - ehuss:update-xcode, r=Mark-Simulacrum
(ci) Update macOS Xcode to 15

This updates the macOS builders to Xcode 15. The aarch64 images will be removing Xcode 14 and 16 very soon (https://github.com/actions/runner-images/issues/10703), so we will need to make the switch to continue operating. The linked issue also documents GitHub's new policy for how they will be updating Xcode in the future. Also worth being aware of is the future plans for x86 runners documented in https://github.com/actions/runner-images/issues/9255 and https://github.com/actions/runner-images/issues/10686, which will impact our future upgrade behaviors.

I decided to also update the Xcode in the x86_64 runners, even though they are not being removed. It felt better to me to have all macOS runners on the same (major) version of Xcode. However, note that the x86_64 runners do not have the latest version of 15 (15.4), so I left them at 15.2 (which is currently the default Xcode of the runner).

Xcode 15 was previously causing problems (see #121058) which seem to be resolved now. `@bjorn3` fixed the `invalid r_symbolnum` issue with cranelift. The issue with clang failing to link seems to be fixed, possibly by the update of the pre-built LLVM from 14 to llvm 15 in https://github.com/rust-lang/rust/pull/124850, or an update in our source version of LLVM. I have run some try builds and at least LLVM seems to build (I did not run any tests).

Closes #121058
2024-10-21 20:19:06 +00:00
Eric Huss
16b91e887a Update debuginfo test for newer lldb
For reasons I don't understand, lldb in Xcode 15 no longer prints objects as:

(long) $0 = 19

instead, it is printing them as:

(long) 19
2024-10-21 11:40:12 -07:00
bors
fa815a1cbb Auto merge of #18360 - roife:safe-kw-3, r=Veykril
feat: better completions for extern blcoks

This PR refactors `add_keywords` (making it much clearer!) and enhances completion for `extern` blocks.

It is recommended to reviewing the changes in order of the commits:

- The first commit (f3c4dde0a4917a2bac98605cc045eecfb4d69872) doesn’t change any logic but refactors parts of the `add_keywords` function and adds detailed comments.
- The second commit (5dcc1ab649bf8a49cadf006d620871b12f093a2f) improves completion for `extern` kw and extern blocks.
2024-10-21 17:59:05 +00:00
bors
31e102c509 Auto merge of #132005 - matthiaskrgr:rollup-ced4upi, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #130350 (stabilize Strict Provenance and Exposed Provenance APIs)
 - #131737 (linkchecker: add a reminder on broken links to add new/renamed pages to `SUMMARY.md` for mdBooks)
 - #131991 (test: Add test for trait in FQS cast, issue #98565)
 - #131997 (Make `rustc_abi` compile on stable again)
 - #131999 (Improve test coverage for `unit_bindings` lint)
 - #132001 (fix coherence error for very large tuples™)
 - #132003 (update ABI compatibility docs for new option-like rules)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-21 17:33:42 +00:00
roife
ad27b8225f minor: refactor completions in item_list 2024-10-22 01:31:57 +08:00
Ralf Jung
d567fcc301 abi/compatibility: also test Option-like types 2024-10-21 18:24:45 +01:00
onur-ozkan
774201e3b6 don't stage-off to previous compiler when CI rustc is available
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-10-21 19:34:41 +03:00
Matthias Krüger
64f4aa6725
Rollup merge of #132003 - RalfJung:abi-compat-docs, r=traviscross
update ABI compatibility docs for new option-like rules

Documents the rules decided [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599) for our ABI compatibility rules.

Long-term this should be moved to the reference, but for now this is what we got.

Cc `@rust-lang/lang` `@rust-lang/opsem`
2024-10-21 18:11:23 +02:00