This is more useful than `allow` as compiler will force us to remove rules
that are no longer valid (we already got 2 of them in this change).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Use sa_sigaction instead of sa_union.__su_sigaction for AIX
Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](https://github.com/rust-lang/libc/pull/4250)).
Rustdoc: remove a bunch of @ts-expect-error from main.js
r? ```````@notriddle```````
Most remaining instances of ````````@ts-expect-error```````` in `search.js` and `main.js` are some sort of unchecked assertion, most of them involving nullibility, and we have yet to decide on how to handle these.
Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs
In #137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system:
```rust
trait Foo<T> {
fn bar<const N: T>() {}
}
```
This PR does a few things:
1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled.
2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled.
3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3
r? `@BoxyUwU` or reassign
Support rmeta inputs for --crate-type=bin --emit=obj
This already works for --emit=metadata, but is possible anytime we're not linking.
Tests:
- `rmeta_bin` checks we're not changing --emit=link (already passes)
- `rmeta_bin-pass` tests the new behavior for --emit=obj (would fail today) and also --emit=metadata which isn't changing
uefi: fs: Implement FileType, FilePermissions and FileAttr
- In UEFI, both FileType and FilePermissions are represented by the attr bitfield.
- Using simple bools here since both are represented by a single bit.
- Add `FILE_PERMISSION` mask for constructing attribute while change permissions.
cc ````@nicholasbishop````
Convert `ShardedHashMap` to use `hashbrown::HashTable`
The `hash_raw_entry` feature (#56167) has finished fcp-close, so the compiler
should stop using it to allow its removal. Several `Sharded` maps were
using raw entries to avoid re-hashing between shard and map lookup, and
we can do that with `hashbrown::HashTable` instead.
change definitely unproductive cycles to error
builds on top of #136824 by adding a third variant to `PathKind` for paths which may change to be coinductive in the future but must not be so right now. Most notably, impl where-clauses of not yet coinductive traits.
With this, we can change cycles which are definitely unproductive to a proper error. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/114. This does not affect stable as we keep these cycles as ambiguous during coherence.
r? ````````@compiler-errors```````` ````````@nikomatsakis````````
Update bootstrap to edition 2024
The stage0 compiler now supports edition 2024, so we can update bootstrap to it. I manually reviewed all the changes from `cargo fix --edition` and reverted most of them (`if let` -> `matches` changes and two unneeded usages of `use <>`).
r? `@onur-ozkan`
try-job: dist-x86_64-msvc
Fix false-positive in `expr_or_init` and in the `invalid_from_utf8` lint
This PR fixes the logic for finding initializer in the `expr_or_init` and `expr_or_init_with_outside_body` functions.
If the binding were to be mutable (`let mut`), the logic wouldn't consider that the initializer expression could have been modified and would return the init expression even-trough multiple subsequent assignments could have been done.
Example:
```rust
let mut a = [99, 108, 130, 105, 112, 112]; // invalid, not UTF-8
loop {
a = *b"clippy"; // valid
break;
}
std::str::from_utf8_mut(&mut a); // currently warns, with this PR it doesn't
```
This PR modifies the logic to excludes mutable let bindings.
Found when using `expr_or_init` in https://github.com/rust-lang/rust/pull/119220.
r? compiler
Update books
## rust-lang/book
11 commits in 4a01a9182496f807aaa5f72d93a25ce18bcbe105..81a976a237f84b8392c4ce1bd5fd076eb757a2eb
2025-02-27 22:10:41 UTC to 2025-02-24 18:36:27 UTC
- Ch. 10: Make social media discussion generic. (rust-lang/book#4249)
- Another Ch. 17 -> 18 fix (rust-lang/book#4247)
- Ch. 05: further tweak to wording about `user1` availability (rust-lang/book#4246)
- Ch. 02: Fix rand version mistake (from testing) (rust-lang/book#4245)
- Ch. 19: Correct the discussion of `fn` type and closures (rust-lang/book#4244)
- Edition maintenance: scripting the updates for future work (rust-lang/book#4243)
- Ch. 17: fresh-eyes edits (rust-lang/book#4242)
- Ch. 17: drop lifetime not required in 2024 Edition (rust-lang/book#4212)
- Appendix B, Operators: Replace “member access” with “field access” and “method call”. (rust-lang/book#4240)
- Update to Rust 1.85 and 2024 Edition! (rust-lang/book#4241)
- Chapter 1: fix 'four things' now that spacing is not emphasized (rust-lang/book#4239)
## rust-lang/edition-guide
2 commits in daa4b763cd848f986813b5cf8069e1649f7147af..1e27e5e6d5133ae4612f5cc195c15fc8d51b1c9c
2025-03-04 22:02:00 UTC to 2025-02-26 12:47:41 UTC
- Mention both `rustfmt.toml` and `.rustfmt.toml` (rust-lang/edition-guide#372)
- Fix a typo (rust-lang/edition-guide#370)
## rust-lang/nomicon
1 commits in 8f5c7322b65d079aa5b242eb10d89a98e12471e1..b4448fa406a6dccde62d1e2f34f70fc51814cdcc
2025-03-01 04:48:05 UTC to 2025-03-01 04:48:05 UTC
- Update to 2024 edition (rust-lang/nomicon#481)
## rust-lang/reference
8 commits in 615b4cec60c269cfc105d511c93287620032d5b0..dda31c85f2ef2e5d2f0f2f643c9231690a30a626
2025-03-09 14:25:25 UTC to 2025-02-25 16:07:17 UTC
- Rework note blocks and change admonition rendering (rust-lang/reference#1754)
- Add more information on rules and tests (rust-lang/reference#1753)
- Mention `explicit_builtin_cfgs_in_flags` lint cfg chapter (rust-lang/reference#1747)
- fixup test links (rust-lang/reference#1741)
- Fix diagnostics typo: `do_no_recommend` -> `do_not_recommend` (rust-lang/reference#1749)
- panic runtime and C-unwind documentation (rust-lang/reference#1226)
- Closures: fix example of desugaring (rust-lang/reference#1743)
- Update boolean.md, Comment breaks paragraph format (rust-lang/reference#1744)
## rust-lang/rust-by-example
1 commits in 66543bbc5b7dbd4e679092c07ae06ba6c73fd912..6f69823c28ae8d929d6c815181c73d3e99ef16d3
2025-03-09 13:12:24 UTC to 2025-03-09 13:12:24 UTC
- Update mdbook to 0.4.46 (rust-lang/rust-by-example#1914)
try-job: x86_64-gnu-distcheck
Elaborate trait assumption in `receiver_is_dispatchable`
Fixes#138172. See comment on the linked test.
Probably not a fix for the general problem, bc I think this may still be incomplete for other weird `where` clauses on the receiver. But 🤷, supertraits seems like an obvious one to fix.
Add PeekMut::refresh
I'm not sure if this should go through ACP or not. BinaryHeap is not the most critical data structure in the standard library and it would be understandable if maintainer throughput is thus too limited to accept this PR without a proper design phase that ensures the required understanding of consequence over a longer time period.
This aims to improve the useability of heaps for priority-based work queues. In certain scenarios, modifications on the most relevant or critical items are performed until a condition that determines the work items have been sufficiently addressed. For instance the criticality could be a deadline that is relaxed whenever some part of a work item is completed. Such a loop will repeatedly access the most critical item and put it back in a sorted position when it is complete. Crucially, due to the ordering invariant we know that all necessary work was performed when the completed item remains the most critical. Getting this information from the heap position avoids a (potentially more costly) check on the item state itself.
A customized `drop` with boolean result would avoid up to two more comparisons performed in both the last no-op refresh and Drop code but this occurs once in each execution of the above scenario whereas refresh occurs any number of times. Also note that the comparison overhead of Drop is only taken if the element is mutably inspected to determine the end condition, i.e. not when refresh itself is the break condition.
