| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=jieyouxu
Migrate `run-make/manual-crate-name` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? ``@jieyouxu``
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Winnow private method candidates instead of assuming any candidate of the right name will apply
partially reverts https://github.com/rust-lang/rust/pull/60721
My original motivation was just to avoid the `delay_span_bug` (by attempting to thread the `ErrorGuaranteed` through to here). But then I realized that the error message is wrong. It refers to the `Foo<A>::foo` instead of `Foo<B>::foo`. This is almost invisible, because both functions are the same, but on different lines, so `-Zui-testing` makes it so the test is the same no matter which of these two functions is referenced.
But there's a much more obvious bug: If `Foo<B>` does not have a `foo` method at all, but `Foo<A>` has a private `foo` method, then we'll refer to that one. This has now been fixed, and we report a normal `method not found` error.
The way this is done is by creating a list of all possible private functions (just like we create a list of the public functions that can actually be called), and then winnowing it by analyzing where bounds and `Self` types to see if any of the found methods can actually apply (again, just like with the list of public functions).
I wonder if there is room for doing the same thing with unstable functions instead of running all of method resolution twice.
r? ``@compiler-errors`` for method resolution stuff
|
|
Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` 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).
Some oddly specific ignore flags in `incr-prev-body-beyond-eof`:
```rs
// ignore-none
// ignore-nvptx64-nvidia-cuda
```
it could be interesting to run a try job, but it seems there is no nvidia-cuda in the CI settings (`jobs.yml`).
try-job: armhf-gnu
|
|
|
|
|
|
|
|
|
|
Rewrite `emit`, `mixing-formats` and `bare-outfile` `run-make` tests in `rmake.rs` 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
|
|
|
|
GuillaumeGomez:migrate-run-make-c-link-to-rust-dylib, r=jieyouxu
Migrate `run-make/c-link-to-rust-dylib` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
First commit comes from https://github.com/rust-lang/rust/pull/125773.
r? `@jieyouxu`
|
|
Migrate `run-make/emit-named-files` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
|
|
|
|
|
|
also improve wording for an ignore reason
|
|
Rollup of 7 pull requests
Successful merges:
- #125653 (Migrate `run-make/const-prop-lint` to `rmake.rs`)
- #125662 (Rewrite `fpic`, `simple-dylib` and `issue-37893` `run-make` tests in `rmake.rs` or ui test format)
- #125699 (Streamline `x fmt` and improve its output)
- #125701 ([ACP 362] genericize `ptr::from_raw_parts`)
- #125723 (Migrate `run-make/crate-data-smoke` to `rmake.rs`)
- #125733 (Add lang items for `AsyncFn*`, `Future`, `AsyncFnKindHelper`'s associated types)
- #125734 (ast: Revert a breaking attribute visiting order change)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=jieyouxu
Migrate `run-make/crate-data-smoke` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? ``@jieyouxu``
|
|
Rewrite `fpic`, `simple-dylib` and `issue-37893` `run-make` tests in `rmake.rs` or ui test 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).
|
|
Migrate `run-make/const-prop-lint` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? ``@jieyouxu``
|
|
Give tidy the good news about C-SKY
It seems this was overlooked in https://github.com/rust-lang/rust/pull/125472 because we don't test C-SKY much yet.
Fixes #125697
r? `@erikdesjardins`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rewrite `lto-smoke`, `simple-rlib` and `mixing-deps` `run-make` tests in `rmake.rs` 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).
|
|
Make more of the test suite run on Mac Catalyst
Combined with https://github.com/rust-lang/rust/pull/125225, the only failing parts of the test suite are in `tests/rustdoc-js`, `tests/rustdoc-js-std` and `tests/debuginfo`. Tested with:
```console
./x test --target=aarch64-apple-ios-macabi library/std
./x test --target=aarch64-apple-ios-macabi --skip=tests/rustdoc-js --skip=tests/rustdoc-js-std --skip=tests/debuginfo tests
```
Will probably put up a PR later to enable _running_ on (not just compiling for) Mac Catalyst in CI, though not sure where exactly I should do so? `src/ci/github-actions/jobs.yml`?
Note that I've deliberately _not_ enabled stack overflow handlers on iOS/tvOS/watchOS/visionOS (see https://github.com/rust-lang/rust/issues/25872), but rather just skipped those tests, as it uses quite a few APIs that I'd be weary about getting rejected by the App Store (note that Swift doesn't do it on those platforms either).
r? ``@workingjubilee``
CC ``@thomcc``
``@rustbot`` label O-ios O-apple
|
|
|
|
|
|
|
|
This adds the `only-apple`/`ignore-apple` compiletest directive, and
uses that basically everywhere instead of `only-macos`/`ignore-macos`.
Some of the updates in `run-make` are a bit redundant, as they use
`ignore-cross-compile` and won't run on iOS - but using Apple in these
is still more correct, so I've made that change anyhow.
|
|
|
|
|
|
|
|
GuillaumeGomez:migrate-rustdoc-verify-output-files, r=jieyouxu
Migrate rustdoc verify output files
Part of https://github.com/rust-lang/rust/issues/121876.
r? ```@jieyouxu```
|
|
The number of tests does not depend on the architecture's pointer width
Use `u32` instead of `usize` for counting them.
|
|
|
|
Migrate `run-make/compile-stdin` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
|
|
tidy: stop special-casing tests/ui entry limit
It is genuinely more annoying to have this error, now that this value is below the general `ENTRY_LIMIT` cap, when one is trying to clean out tests from tests/ui! This code has served its purpose well, let it rest now rather than force it to continue haunting us.
|
|
tidy: validate LLVM component names in tests
LLVM component names are not immediately obvious (they usually omit any suffixes on the target arch name), and if they're incorrect, the test will silently never run.
This happened [here](https://github.com/rust-lang/rust/pull/125220#discussion_r1612626002), and it would be nice to prevent it.
|
|
|
|
LLVM component names are not immediately obvious (they usually omit any
suffixes on the target arch name), and if they're incorrect, the test
will silently never run.
|
|
r=jieyouxu
Migrate `run-make/rustdoc-with-short-out-dir-option` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
GuillaumeGomez:migrate-rustdoc-scrape-examples-macros, r=jieyouxu
Migrate `run-make/rustdoc-scrape-examples-macros` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `````@jieyouxu`````
|
|
Migrate `run-make/issue-30063` 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).
(Sorry about the [inconvenience](https://github.com/rust-lang/rust/pull/125224#issuecomment-2118340932) of all these PRs, this is the last one batched for today. I will discuss how we can cut these down a bit.)
The last check was previously commented out in the Makefile, and I have readded it. If it fails the CI, this can be reconsidered.
|
|
Migrate `run-make/issue-53964` 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).
This is extremely similar to #125146. Could it be interesting to merge the two in some way? This one seems to do the same thing as the #125146, but with an added check that a useless lint is not shown.
|
