Automatic Rustup #4001
Merged
Automatic Rustup #4001
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…ompiler-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](rust-lang/rust#86231 (comment)) 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 rust-lang/rust#87678
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](https://github.com/rust-lang/rust/blob/f25e5abea229a6b6aa77b45e21cb784e785c6040/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.
x86-32 float return for 'Rust' ABI: treat all float types consistently This helps with rust-lang/rust#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
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.
…illaumeGomez rustdoc: hash assets at rustdoc build time Since sha256 is slow enough to show up on small benchmarks, we can save time by embedding the hash in the executable. Addresses rust-lang/rust#131934 (comment)
Remove the `Arc` rt::init allocation for thread info Removes an allocation pre-main by just not storing anything in std::thread::Thread for the main thread. - The thread name can just be a hard coded literal, as was done in #123433. - Storing ThreadId and Parker in a static that is initialized once at startup. This uses SyncUnsafeCell and MaybeUninit as this is quite performance critical and we don't need synchronization or to store a tag value and possibly leave in a panic.
Update books ## rust-lang/edition-guide 7 commits in c7ebae25cb4801a31b6f05353f6d85bfa6feedd1..1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9 2024-10-21 14:29:49 UTC to 2024-10-19 19:08:20 UTC - 2024: Add reserved syntax (rust-lang/edition-guide#326) - Update stdout of `cargo new` (rust-lang/edition-guide#327) - Don't run doctests on rustfmt ident sorting page - add rustfmt raw identifer sorting doc (rust-lang/edition-guide#321) - Add some tips for what to be careful of with rustdoc-doctests (rust-lang/edition-guide#323) - Remove cargo-remove-implicit-features (rust-lang/edition-guide#324) - Rename doctest standalone tag (rust-lang/edition-guide#325) ## rust-embedded/book 1 commits in f40a8b420ec4b4505d9489965e261f1d5c28ba23..ddbf1b4e2858fedb71b7c42eb15c4576517dc125 2024-10-13 19:53:37 UTC to 2024-10-13 19:53:37 UTC - Add link to Cortex-M comparison to install.md (rust-embedded/book#378) ## rust-lang/reference 29 commits in c64e52a3d306eac0129f3ad6c6d8806ab99ae2e9..23ce619966541bf2c80d45fdfeecf3393e360a13 2024-10-05 00:33:03 +0000 to 2024-10-22 21:34:51 +0000 - Mention `--print cfg` under set configuration options (rust-lang/reference#1636) - Fix `pat` fragment specifier to be the "current" edition (rust-lang/reference#1640) - Add restriction for cfg_attr with crate_type and crate_name (rust-lang/reference#1649) - Sort macro fragment specifiers (rust-lang/reference#1641) - Document mixed-site hygiene (rust-lang/reference#1656) - Clarify that "macro attributes" refers to proc macros (rust-lang/reference#1660) - mdbook-spec: Fix Spec::new creation (rust-lang/reference#1658) - Fix stdcall example broken by recent rustc change (rust-lang/reference#1659) - Add spec identifiers to const_eval.md (rust-lang/reference#1569) - Add identifier syntax to trait-bounds.md (rust-lang/reference#1631) - Add identifier syntax to macro-ambiguity.md (rust-lang/reference#1634) - Add spec identifier syntax to conditional-compilation.md (rust-lang/reference#1564) - Add spec identifiers to behaviour-considered-undefined.md (rust-lang/reference#1562) - Add test linking (rust-lang/reference#1646) - Allow `deny` inside `forbid` as a no-op (rust-lang/reference#1655) - Add identifier syntax to identifiers.md (rust-lang/reference#1583) - Add spec identifiers to crates-and-source-files.md (rust-lang/reference#1570) - Add identifier syntax to linkage.md (rust-lang/reference#1633) - Add identifier syntax to type-coercions.md (rust-lang/reference#1632) - Add identifiers to variables.md (rust-lang/reference#1626) - Add identifier syntax to lexer chapters (rust-lang/reference#1620) - Add spec identifier syntax to `unsafe-keyword.md` and `unsafety.md` (rust-lang/reference#1619) - Add identifier syntax to types and subchapters. (rust-lang/reference#1618) - Add identifier syntax to subtyping.md (rust-lang/reference#1613) - Add identifier syntax to statements.md (rust-lang/reference#1611) - Add identifier syntax to type-layout.md (rust-lang/reference#1614) - Clarify definition of "immutable bytes" (rust-lang/reference#1637) - Add preview artifacts in CI (rust-lang/reference#1647) - trait bounds grammar: make `?` and `for<>` mutually exclusive (rust-lang/reference#1650) ## rust-lang/rustc-dev-guide 5 commits in 07bc9ca9eb1cd6d9fbbf758c2753b748804a134f..59d94ea75a0b157e148af14c73c2dd60efb7b60a 2024-10-21 02:30:07 UTC to 2024-10-07 21:12:09 UTC - Add the WASM | WASI | Emscripten notification groups (rust-lang/rustc-dev-guide#2100) - Update bootstrapping.md (rust-lang/rustc-dev-guide#1900) - Rename `needs-profiler-support` to `needs-profiler-runtime` (rust-lang/rustc-dev-guide#2095) - Document compiletest directives `ignore-coverage-map` and `ignore-coverage-run` (rust-lang/rustc-dev-guide#2094) - Purge `run-pass-valgrind` mentions (rust-lang/rustc-dev-guide#2091)
Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.) As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code. This commit makes it a post-monomorphization error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI. See the [nomination comment](rust-lang/rust#127731 (comment)) for more discussion. r? RalfJung Part of rust-lang/rust#116558
(Big performance change) Do not run lints that cannot emit Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!) So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either: - Manually `#![allow]`ed in the whole crate, - Allowed in the command line, or - Not manually enabled with `#[warn]` or similar, and its default level is `Allow` As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run) Fixes #106983
Add an unstable `const_sockaddr_setters` feature
Unstably add `const` to the `sockaddr_setters` methods. Included API:
```rust
// core::net
impl SocketAddr {
pub const fn set_ip(&mut self, new_ip: IpAddr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV4 {
pub const fn set_ip(&mut self, new_ip: Ipv4Addr);
pub const fn set_port(&mut self, new_port: u16);
}
impl SocketAddrV6 {
pub const fn set_ip(&mut self, new_ip: Ipv6Addr);
pub const fn set_port(&mut self, new_port: u16);
}
```
Tracking issue: <rust-lang/rust#131714>
rustc_target: Add pauth-lr aarch64 target feature Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19. It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time. r? `@Amanieu`
Miri subtree update r? `@ghost`
Rollup of 5 pull requests Successful merges: - #132043 (Simplify param handling in `resolve_bound_vars`) - #132214 (Cleanup: Move an impl-Trait check from AST validation to AST lowering) - #132221 (Clean up some comments on lint implementation) - #132228 (Revert "ci update freebsd version proposal, freebsd 12 being eol.") - #132234 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
…Jung Make clearer that guarantees in ABI compatibility are for Rust only cc rust-lang/rust#132136 (comment) -- it looks like we already had a note that I missed in my initial look here, but this goes further to emphasize the guarantees, including uplifting it to the top of the general documentation. r? `@RalfJung`
bump stdarch This lets us remove a hack from rust-lang/rust#131349. r? `@Amanieu` try-job: test-various
After moving some `Box` internals to a different module, the path in the diagnostic changed.
Lint against getting pointers from immediately dropped temporaries Fixes #123613 ## Changes: 1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary. 2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`. 3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`. 4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments. 5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"` ## Questions: - [ ] Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? rust-lang/rust#128985 (comment) ## Known limitations: ### False negatives[^fn]: See the comments in `compiler/rustc_lint/src/dangling.rs` 1. Method calls that are not checked for: - `temporary_unsafe_cell.get()` - `temporary_sync_unsafe_cell.get()` 2. Ways to get a temporary that are not recognized: - `owning_temporary.field` - `owning_temporary[index]` 3. No checks for ref-to-ptr conversions: - `&raw [mut] temporary` - `&temporary as *(const|mut) _` - `ptr::from_ref(&temporary)` and friends [^fn]: lint **should** be emitted, but **is not** [^fp]: lint **should not** be emitted, but **is**
compiler: apply clippy::clone_on_ref_ptr for CI Apply lint https://rust-lang.github.io/rust-clippy/master/index.html#/clone_on_ref_ptr for compiler, also see rust-lang/rust#131225 (comment). Some Arc's can be misplaced with Lrc's, sorry. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/enable.20more.20clippy.20lints.20for.20compiler.20.28and.5Cor.20std.29
Mark `str::is_char_boundary` and `str::split_at*` unstably `const`. Tracking issues: #131516, #131518 First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`) ~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~ This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.
Collect item bounds for RPITITs from trait where clauses just like associated types
We collect item bounds from trait where clauses for *associated types*, i.e. this:
```rust
trait Foo
where
Self::Assoc: Send
{
type Assoc;
}
```
Becomes this:
```rust
trait Foo {
type Assoc: Send;
}
```
Today, with RPITITs/AFIT and return-type notation, we don't do that, i.e.:
```rust
trait Foo where Self::method(..): Send {
fn method() -> impl Sized;
}
fn is_send(_: impl Send) {}
fn test<T: Foo>() {
is_send(T::method());
}
```
...which fails on nightly today.
Turns out it's super easy to fix this, and we just need to use the `associated_type_bounds` lowering function in `explicit_item_bounds_with_filter`, which has that logic baked in.
correct LLVMRustCreateThinLTOData arg types
`LLVMRustCreateThinLTOData` defined in rust as
```rust
pub fn LLVMRustCreateThinLTOData(
Modules: *const ThinLTOModule,
NumModules: c_uint,
PreservedSymbols: *const *const c_char,
PreservedSymbolsLen: c_uint,
) -> Option<&'static mut ThinLTOData>;
```
but in cpp as
```cpp
extern "C" LLVMRustThinLTOData *
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules, int num_modules,
const char **preserved_symbols, int num_symbols) {
```
(note `c_unit` vs `int` types). Let it be actually `size_t`.
Also fixes return type of `LLVMRustDIBuilderCreateOpLLVMFragment` to uint64_t as other similar functions around, which should be correct, i assume.
…ilee Split `boxed.rs` into a few modules I wanted to add an impl for `Box<_>`, but was quickly discouraged by the 3K file. This splits off a couple bits, making it at least a bit more manageable. r? ````@workingjubilee```` (I think you are not bothered by refactorings like this?)
…beetrees,workingjubilee riscv-soft-abi-with-float-features.rs: adapt for LLVM 20 Adapts a test for LLVM 20. No functional changes intended.
clarified doc for `std::fs::OpenOptions.truncate()` Clarified what method does when `std::fs::OpenOptions.truncate()` parameter is set to `true`.
Remove my ping for rustdoc/clean/types.rs It was useful at one time, but now it just causes notification noise.
Remove myself from mentions inside `tests/ui/check-cfg` directory This PR removes myself from mentions inside `tests/ui/check-cfg` directory. I'm not sure this particular mention has ever been useful to me, and lately it's been too annoying for me to ignore it. So remove my-self from it.
Delete `tests/crashes/23707.rs` because it's flaky It's conditioned on `only-x86_64` because it doesn't reliably fail on other platforms, it's optimization dependent and failed to ICE post-PGO in <rust-lang/rust#132300 (comment)>. Remove this test for now without prejudice against relanding the test in a more reliable form. I removed the `S-bug-has-test` label from #23707. r? compiler
compiletest: Rename `command-list.rs` to `directive-list.rs` Because I forget the name of this file literally every single time I need to find and edit it. r? jieyouxu
Rollup of 12 pull requests Successful merges: - #131375 (compiler: apply clippy::clone_on_ref_ptr for CI) - #131520 (Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.) - #132119 (Hack out effects support for old solver) - #132194 (Collect item bounds for RPITITs from trait where clauses just like associated types) - #132216 (correct LLVMRustCreateThinLTOData arg types) - #132233 (Split `boxed.rs` into a few modules) - #132266 (riscv-soft-abi-with-float-features.rs: adapt for LLVM 20) - #132270 (clarified doc for `std::fs::OpenOptions.truncate()`) - #132284 (Remove my ping for rustdoc/clean/types.rs) - #132293 (Remove myself from mentions inside `tests/ui/check-cfg` directory) - #132312 (Delete `tests/crashes/23707.rs` because it's flaky) - #132313 (compiletest: Rename `command-list.rs` to `directive-list.rs`) r? `@ghost` `@rustbot` modify labels: rollup
Rc/Arc: don't leak the allocation if drop panics Currently, when the last `Rc<T>` or `Arc<T>` is dropped and the destructor of `T` panics, the allocation will be leaked. This leak is unnecessary since the data cannot be (safely) accessed again and `Box` already deallocates in this case, so let's do the same for `Rc` and `Arc`, too.
Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation. As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1] It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation. [^1]: https://rust.godbolt.org/z/ravE75EYj [^2]: https://rust.godbolt.org/z/fzr171zKh r? libs
|
CI seems to have been canceled for no apparent reason? |
|
Ah, maybe this was a timeout. Some of the jobs don't even seem to have started. |
|
I checked that website before writing my comment... Seems like it was not up to date at that point. Oh well.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please close and re-open this PR to trigger CI, then enable auto-merge.