Stablize {HashMap,BTreeMap}::into_{keys,values}
I would propose to stabilize `{HashMap,BTreeMap}::into_{keys,values}`( aka. `map_into_keys_values`).
Closes#75294.
Fix#84467 linker_args with --target=sparcv9-sun-solaris
Trying to cross-compile for sparcv9-sun-solaris
getting a error message for -zignore
Introduced when -z -ignore was seperated here
22d0ab0
No formatting done
Reproduce
``` bash
rustup target add sparcv9-sun-solaris
cargo new --bin hello && cd hello && cargo run --target=sparcv9-sun-solaris
```
config.toml
[target.sparcv9-sun-solaris]
linker = "gcc"
alloc: Add unstable Cfg feature `no-global_oom_handling
For certain sorts of systems, programming, it's deemed essential that
all allocation failures be explicitly handled where they occur. For
example, see Linus Torvald's opinion in [1]. Merely not calling global
panic handlers, or always `try_reserving` first (for vectors), is not
deemed good enough, because the mere presence of the global OOM handlers
is burdens static analysis.
One option for these projects to use rust would just be to skip `alloc`,
rolling their own allocation abstractions. But this would, in my
opinion be a real shame. `alloc` has a few `try_*` methods already, and
we could easily have more. Features like custom allocator support also
demonstrate and existing to support diverse use-cases with the same
abstractions.
A natural way to add such a feature flag would a Cargo feature, but
there are currently uncertainties around how std library crate's Cargo
features may or not be stable, so to avoid any risk of stabilizing by
mistake we are going with a more low-level "raw cfg" token, which
cannot be interacted with via Cargo alone.
Note also that since there is no notion of "default cfg tokens" outside
of Cargo features, we have to invert the condition from
`global_oom_handling` to to `not(no_global_oom_handling)`. This breaks
the monotonicity that would be important for a Cargo feature (i.e.
turning on more features should never break compatibility), but it
doesn't matter for raw cfg tokens which are not intended to be
"constraint solved" by Cargo or anything else.
To support this use-case we create a new feature, "global-oom-handling",
on by default, and put the global OOM handler infra and everything else
it that depends on it behind it. By default, nothing is changed, but
users concerned about global handling can make sure it is disabled, and
be confident that all OOM handling is local and explicit.
For this first iteration, non-flat collections are outright disabled.
`Vec` and `String` don't yet have `try_*` allocation methods, but are
kept anyways since they can be oom-safely created "from parts", and we
hope to add those `try_` methods in the future.
[1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/
This commit implements both the native linking modifiers infrastructure
as well as an initial attempt at the individual modifiers from the RFC.
It also introduces a feature flag for the general syntax along with
individual feature flags for each modifier.
For certain sorts of systems, programming, it's deemed essential that
all allocation failures be explicitly handled where they occur. For
example, see Linus Torvald's opinion in [1]. Merely not calling global
panic handlers, or always `try_reserving` first (for vectors), is not
deemed good enough, because the mere presence of the global OOM handlers
is burdens static analysis.
One option for these projects to use rust would just be to skip `alloc`,
rolling their own allocation abstractions. But this would, in my
opinion be a real shame. `alloc` has a few `try_*` methods already, and
we could easily have more. Features like custom allocator support also
demonstrate and existing to support diverse use-cases with the same
abstractions.
A natural way to add such a feature flag would a Cargo feature, but
there are currently uncertainties around how std library crate's Cargo
features may or not be stable, so to avoid any risk of stabilizing by
mistake we are going with a more low-level "raw cfg" token, which
cannot be interacted with via Cargo alone.
Note also that since there is no notion of "default cfg tokens" outside
of Cargo features, we have to invert the condition from
`global_oom_handling` to to `not(no_global_oom_handling)`. This breaks
the monotonicity that would be important for a Cargo feature (i.e.
turning on more features should never break compatibility), but it
doesn't matter for raw cfg tokens which are not intended to be
"constraint solved" by Cargo or anything else.
To support this use-case we create a new feature, "global-oom-handling",
on by default, and put the global OOM handler infra and everything else
it that depends on it behind it. By default, nothing is changed, but
users concerned about global handling can make sure it is disabled, and
be confident that all OOM handling is local and explicit.
For this first iteration, non-flat collections are outright disabled.
`Vec` and `String` don't yet have `try_*` allocation methods, but are
kept anyways since they can be oom-safely created "from parts", and we
hope to add those `try_` methods in the future.
[1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/
Rollup of 11 pull requests
Successful merges:
- #83553 (Update `ptr` docs with regards to `ptr::addr_of!`)
- #84183 (Update RELEASES.md for 1.52.0)
- #84709 (Add doc alias for `chdir` to `std::env::set_current_dir`)
- #84803 (Reduce duplication in `impl_dep_tracking_hash` macros)
- #84808 (Account for unsatisfied bounds in E0599)
- #84843 (use else if in std library )
- #84865 (rustbuild: Pass a `threads` flag that works to windows-gnu lld)
- #84878 (Clarify documentation for `[T]::contains`)
- #84882 (platform-support: Center the contents of the `std` and `host` columns)
- #84903 (Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`)
- #84913 (Do not ICE on invalid const param)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE on invalid const param
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Remove `rustc_middle::mir::interpret::CheckInAllocMsg::NullPointerTest`
Removing it per https://github.com/rust-lang/rust/pull/84842#discussion_r625589674: it's a dead enum variant.
Note that `PointerArithmeticTest` also seems dead:
```
$ rg -F PointerArithmeticTest -C5
compiler/rustc_middle/src/mir/interpret/error.rs
169-
170-/// Details of why a pointer had to be in-bounds.
171-#[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)]
172-pub enum CheckInAllocMsg {
173- MemoryAccessTest,
174: PointerArithmeticTest,
175- InboundsTest,
176-}
177-
178-impl fmt::Display for CheckInAllocMsg {
179- /// When this is printed as an error the context looks like this
--
182- write!(
183- f,
184- "{}",
185- match *self {
186- CheckInAllocMsg::MemoryAccessTest => "memory access",
187: CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic",
188- CheckInAllocMsg::InboundsTest => "inbounds test",
189- }
190- )
191- }
192-}
```
Not sure if that is also desirable to be removed, however.
Clarify documentation for `[T]::contains`
Change the documentation to correctly characterize when the suggested alternative to `contains` applies, and correctly explain why it works.
Fixes#84877
rustbuild: Pass a `threads` flag that works to windows-gnu lld
MinGW driver for COFF LLD doesn't currently translate GNU-style `--threads=N` to native `/threads:N`, so we have to pass the option in its native form to avoid an error.
Also pass the `threads` flag to lld-link (windows-msvc lld) as well.
Add doc alias for `chdir` to `std::env::set_current_dir`
Searching for `chdir` in the Rust documentation produces no useful
results.
I wrote some code recently that called `libc::chdir` and manually
handled errors, because I didn't realize that the safe
`std::env::set_current_dir` existed. I searched for `chdir` and
`change_dir` and `change_directory` (the latter two based on the
precedent of unabbreviating set by `create_dir`), and I also read
through `std::fs` expecting to potentially find it there. Given that
none of those led to `std::env::set_current_dir`, I think that provides
sufficient justification to add this specific alias.
Update `ptr` docs with regards to `ptr::addr_of!`
This updates the documentation since `ptr::addr_of!` and `ptr::addr_of_mut!` are now stable. One might remove the distinction between the sections `# On packed structs` and `# Examples`, as the old section on packed structs was primarily to prevent users of doing undefined behavior, which is not necessary anymore.
Technically there is now wrong/outdated documentation on stable, but I don't think this is worth a point release 😉Fixes#83509.
``````````@rustbot`````````` modify labels: T-doc
Move all `sys::ext` modules to `os`
This PR moves all `sys::ext` modules to `os`, centralizing the location of all `os` code and simplifying the dependencies between `os` and `sys`.
Because this also removes all uses `cfg_if!` on publicly exported items, where after #81969 there were still a few left, this should properly work around https://github.com/rust-analyzer/rust-analyzer/issues/6038.
`@rustbot` label: +T-libs-impl
Update RLS and Rustfmt
Closes#84537. Closes#84538.
I know there's https://github.com/rust-lang/rust/pull/82208 in progress but I'm not sure which we want to land first.
Also, I'm getting Rustfmt test failures due to inner attributes not permitted:
<details>
```
error: an inner attribute is not permitted in this context
--> tests/target/issue-3592.rs:4:13
|
4 | #![cfg(unix)]
| ^^^^^^^^^^^^^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
error: an inner attribute is not permitted in this context
--> tests/target/issue-3592.rs:8:13
|
8 | #![cfg(not(unix))]
| ^^^^^^^^^^^^^^^^^^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
error: an inner attribute is not permitted in this context
--> tests/source/match.rs:413:9
|
413 | #![allow(simple_match)]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
error: an inner attribute is not permitted in this context
--> tests/target/match.rs:444:9
|
444 | #![allow(simple_match)]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
test test::system_tests ... FAILED
test test::idempotence_tests ... FAILED
```
</details>
but let's see what CI says, first.
cc `@calebcartwright`
Deduplicate native libs before they are passed to the linker
Stop spamming the linker with the same native library over and over again, if they directly follow from each other. This would help prevent [this situation](https://github.com/MSxDOS/ntapi/issues/2).
Issue #38460 has been open since 2016 so I think it's worth making an incomplete fix that at least addresses the most common symptom and without otherwise changing how Rust handles native libs. This PR is intended to be easy to revert (if necessary) when a more permanent fix is implemented.
Retain data in vectorized registers for longer
This seems to be a mild performance improvement on the keccak crate at least, though not sure it'll show up more broadly.
Get rid of fake `DefId`s in rustdoc
Right now there are *many* errors left, but I wanted to show the current state since all that is left to do is fixing the errors.
Resolves#83183
r? `@jyn514`
When encountering a path that can't have generics, do not call
`generics_of`. This would happen when writing something like
`path::this_is_a_mod<const_val>`.
Fix#84831.
Valid underscores in hex/octal/binary literal docs
Currently hex/octal/binary literals with computed values are displayed like `0_xff_fff_fffu32`, which is invalid since underscores can't be in the middle of integer prefixes. This properly formats prefixed integers.
This causes [`std::u32::MAX`](https://doc.rust-lang.org/std/u32/constant.MAX.html) to be displayed as
```rust
pub const MAX: u32 = u32::MAX; // 0_xff_fff_fffu32
```
This PR changes it to be displayed as:
```rust
pub const MAX: u32 = u32::MAX; // 0xffff_ffffu32
```
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021
This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.
r? `@estebank`
CI: Extract LLVM win64 installer directly, using 7z
Currently, we have LLVM tarballs for win64, generated by someone running
the installer via wine and tarring up the result.
7z knows how to extract NSIS installers directly, and the result is
identical to our tarball, except that it doesn't include `Uninstall.exe`
(which we don't care about) and it includes the NSIS plugin directory
(which we also don't care about).
This simplifies the process of upgrading CI, and allows us to just
mirror the upstream release .exe directly. This also improves our
supply chain.
Currently hex/octal/binary literals with computed values are displayed
like `0_xff_fff_fffu32`, which is invalid since underscores can't be in
the middle of integer prefixes. This properly formats prefixed integers.
This updates the documentation since `ptr::addr_of!` and
`ptr::addr_of_mut!` are now stable. One might remove the distinction
between the sections `# On packed structs` and `# Examples`, as the old
section on packed structs was primarily to prevent users of doing unde-
fined behavior, which is not necessary anymore.
There is also a new section in "how to obtain a pointer", which referen-
ces the `ptr::addr_of!` macros.
This commit contains squashed commits from code review.
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Co-authored-by: Soveu <marx.tomasz@gmail.com>
Co-authored-by: Ralf Jung <post@ralfj.de>
Currently, we have LLVM tarballs for win64, generated by someone running
the installer via wine and tarring up the result.
7z knows how to extract NSIS installers directly, and the result is
identical to our tarball, except that it doesn't include `Uninstall.exe`
(which we don't care about) and it includes the NSIS plugin directory
(which we also don't care about).
This simplifies the process of upgrading CI, and allows us to just
mirror the upstream release .exe directly. This also improves our
supply chain.
