```
error: unexpected `...`
--> $DIR/varargs-in-closure-isnt-supported.rs:5:20
|
LL | let mut lol = |...| ();
| ^^^ not a valid pattern
|
= note: C-variadic type `...` is not allowed here
```
Move more early buffered lints to dyn lint diagnostics
Follow-up to rust-lang/rust#145747.
Presently, it's unclear to me if it's possible to migrate all variants to dyn lint diagnostics without regressing performance because for some early lints `decorate_builtin_lint` performs a bit more work (past PR rust-lang/rust#124417 has shown that eagerly decorating early lints is incredibly heavy and we had to revert back to lazily decorating in rust-lang/rust#125410). Let's see how this fares once I tackle the more 'risky' variants.
cc `@joshtriplett` (you can immediately unsubscribe again, I just want to prevent duplicate efforts).
document `core::ffi::VaArgSafe`
tracking issue: https://github.com/rust-lang/rust/issues/44930
A modification of https://github.com/rust-lang/rust/pull/146454, keeping just the documentation changes, but not unsealing the trait.
Although conceptually we'd want to unseal the trait, there are many edge cases to supporting arbitrary types. We'd need to exhaustively test that all targets/calling conventions support all types that rust might generate (or generate proper error messages for unsupported cases). At present, many of the `va_arg` implementations assume that the argument is a scalar, and has an alignment of at most 8. That is totally sufficient for an MVP (accepting all of the "standard" C types), but clearly does not cover all rust types.
This PR also adds some various other tests for edge cases of c-variadic:
- the `#[inline]` attribute in its various forms. At present, LLVM is unable to inline c-variadic functions, but the attribute should still be accepted. `#[rustc_force_inline]` already rejects c-variadic functions.
- naked functions should accept and work with a C variable argument list. In the future we'd like to allow more ABIs with naked functions (basically, any ABI for which we accept defining foreign c-variadic functions), but for now only `"C"` and `"C-unwind` are supported
- guaranteed tail calls: c-variadic functions cannot be tail-called. That was already rejected, but there was not test for it.
r? `@workingjubilee`
Update the arm-* and aarch64-* platform docs.
This PR updates some of the arm*-unknown-none target docs, and adds some missing target pages.
## aarch64-none-elf and aarch64-none-elf-softfloat
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.
## armv7a-none-eabi and armv7a-none-eabihf
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and a target page is added. Links are added to the EDWG's support crates for this target.
## armv7r-none-eabi and armv7r-none-eabihf
The Rust Embedded Devices Working Group's Arm Team is added as a maintainer, and the target page is split from the Big Endian versions. Links are added to the EDWG's support crates for this target.
## armebv7r-none-eabi and armveb7r-none-eabihf
The target page is split from the Little Endian versions. No change in maintainers.
I have agreement to add EDWG/T-Arm as maintainers, which was voted upon in [their repo](https://github.com/rust-embedded/wg/issues/851).
Some hygiene doc improvements
Improve some doc comments around SyntaxContext, outer_expn and friends.
Based on discussion at https://github.com/rust-lang/rust/pull/146100.
r? petrochenkov
Document `become` keyword
The feature is not yet implemented, so I'm not sure if we should merge this _right away_, promoting an incomplete feature is probably not the best idea. But the docs can be reviewed while the implementation work is being done.
update fixme in compare_method_predicate_entailment resulting from review of EII
r? `@lcnr`
Just the comment update separately from https://github.com/rust-lang/rust/pull/146348/files since it doesn't really belong in that PR. Should be trivial
This is important to note, as it affects how easy it is to build a
binary, and that `#![no_std]` is mandatory.
A different PR should probably add this to all the other platform pages.
Make `AssocItem` aware of its impl kind
The general goal is to have fewer query dependencies by making `AssocItem` aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.
See individual commits.
bootstrap: rustdoc-js tests can now be filtered by js files
Before, a command like `./x test tests/rustdoc-js/path-ordering.js` would succeed, but run no tests, since the names of the tests are based on the `.rs` file. This is a bit confusing, as the `rustdoc-js-std` test suite only has `.js` files, and thus those are the files you filter on. Now, `./x test tests/rustdoc-js/path-ordering.js` will be treated as an alias for `./x test tests/rustdoc-js/path-ordering.rs`. This is fairly simple as each `rustdoc-js` test has 2 files, 1 js file and one rust file, each with an identical base filename, so all we need to do is swap the extension.
r? `@Kobzol`
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#3 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
Add --print target-spec-json-schema
This schema is helpful for people writing custom target spec JSON. It can provide autocomplete in the editor, and also serves as documentation when there are documentation comments on the structs, as `schemars` will put them in the schema.
I was motivated to do this because I saw someone write their own version of this schema by hand, so demand for this clearly exists. It's not a lot of effort to implement, so I thought it would make sense.
MCP: https://github.com/rust-lang/compiler-team/issues/905
I think it would also be useful to put this in the sysroot in `etc` so people can link it directly in their editors.
I would have loved to add a test that validates the JSON schema against the spec JSON of every builtin target, but I don't want to do it as the JSON schema validation crates have incredible amounts of dependencies because JSON schema supports a ton of random features. I don't want to add that, even as a dev dependency.
Improve `core::hash` coverage
This PR improves the `core::hash` coverage by adding a new test to `coretests` and extending one of the existing tests to use 128-bit integers
r? libs
Improve `alloc::Layout` coverage
This PR improves the `core::alloc` coverage by adding a new test to `coretests` that cover the `Layout` methods when they error.
Tracking issue: https://github.com/rust-lang/rust/issues/55724
Convert `no_std` and `no_core` to the new attribute infrastructure
r? ```@oli-obk```
Also added a test for these, since we didn't have any and I was kind of surprised new diagnostics didn't break anything hehe
bootstrap: Build jemalloc for LoongArch with support for 16K pages
By default, jemalloc is configured with a 4K page size. If the host’s page size is larger than this, it will crash at runtime. This patch raises the page size to 16K.
