Rollup of 8 pull requests #122117

Clarify the FatalErrorHandler API that we use: - Identify rustc's LLVM ERRORs by prefixing them - Comment heavily on its interior, while we are here

C++ style guides I am aware of recommend specifically preferring = syntax for any classes with fairly obvious constructors[^0] that do not perform any complicated logic in their constructor. I contend that all constructors that the `rustc_llvm` code uses qualify. This has only become more common since C++ 17 guaranteed many cases of copy initialization elision. The other detail is that I tried to ask another contributor with infinitely more C++ experience than me (i.e. any) what this constructor syntax was, and they thought it was a macro. I know of no other language that has adopted this same syntax. As the rustc codebase features many contributors experienced in many other languages, using a less... unique... style has many other benefits in making this code more lucid and maintainable, which is something it direly needs. [^0]: e.g. https://abseil.io/tips/88

… of slice

As the FIXME itself notes, there's nothing to fix here.

This commit is extracted from rust-lang#122036 and adds a new directive to the `compiletest` test runner, `//@ needs-threads`. This is intended to capture the need that a target must implement threading to execute a specific test, typically one that uses `std::thread`. This is primarily done for WebAssembly targets which currently do not have threads by default. This enables transitioning a lot of `//@ ignore-wasm*`-style ignores into a more self-documenting `//@ needs-threads` directive. Additionally the `wasm32-wasi-preview1-threads` target, for example, does actually have threads, but isn't tested in CI at this time. This change enables running these tests for that target, but not other wasm targets.

Add better explanation for `rustc_index::IndexVec` I feel like I didn't do a great job explaining what this does in rust-lang#119800, so this PR tries to give an example of why and how you would use it. Addresses rust-lang#93792.

…r=cuviper Clarify FatalErrorHandler - Identify rustc's LLVM ERRORs by prefixing them - Comment heavily on its interior, while we are here

… r=cuviper Explicitly assign constructed C++ classes C++ style guides I am aware of recommend specifically preferring = syntax for any classes with fairly obvious constructors[^0] that do not perform any complicated logic in their constructor. I contend that all constructors that the `rustc_llvm` code uses qualify. This has only become more common since C++ 17 guaranteed many cases of copy initialization elision. The other detail is that I tried to ask another contributor with infinitely more C++ experience than me (i.e. any) what this constructor syntax was, and they thought it was a macro. I know of no other language that has adopted this same syntax. As the rustc codebase features many contributors experienced in many other languages, using a less... unique... style has many other benefits in making this code more lucid and maintainable, which is something it direly needs. [^0]: e.g. https://abseil.io/tips/88

Refer to "slice" instead of "vector" in Ord and PartialOrd trait impl of slices The trait implementation comments of Ord and PartialOrd for slice incorrectly mention "vectors" instead of "slices". This PR fixes those two comments as requested in rust-lang#122071.

Remove unnecessary fixme on new thread stack size As the FIXME itself notes, there's nothing to fix here. And as the documentation for [`CreateThread`] says of `dwStackSize`, the value is rounded up to the nearest page. A 4kb stack is very small but perfectly usable if you're careful. Of course it will be very limited but there's no reason to add artificial limits. We don't know what the user is doing. [`CreateThread`]: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createthread

…, r=workingjubilee Remove outdated footnote "missing-stack-probe" in platform-support ... after rust-lang#120055 and rust-lang#118491. cc rust-lang#77071 (comment).

…eLapkin Temporarily make allow-by-default the `non_local_definitions` lint T-lang [decided in their triage meeting](https://hackmd.io/U-CKiZx_RKiaANAPXtWf7g#non_local_definitions-common-issues-impl-for-ampLocal-FromltLocalgt-for-Global-%E2%80%A6-rust121621) to try to use a [better logic](rust-lang#121621 (comment)) for detecting non-local `impl` definitions given the [numerous reports](rust-lang#121621) we got. Until that is done and also because the beta cut is next week, switch the lint to allow-by-default until it's implemented. r? `@WaffleLapkin`

…reads, r=workingjubilee compiletest: Add a `//@ needs-threads` directive This commit is extracted from rust-lang#122036 and adds a new directive to the `compiletest` test runner, `//@ needs-threads`. This is intended to capture the need that a target must implement threading to execute a specific test, typically one that uses `std::thread`. This is primarily done for WebAssembly targets which currently do not have threads by default. This enables transitioning a lot of `//@ ignore-wasm*`-style ignores into a more self-documenting `//@ needs-threads` directive. Additionally the `wasm32-wasi-preview1-threads` target, for example, does actually have threads, but isn't tested in CI at this time. This change enables running these tests for that target, but not other wasm targets.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 8 pull requests #122117

Rollup of 8 pull requests #122117

Commits on Mar 6, 2024