Deduplicate ParamCandidates with the same value except for bound vars
Fixes#84398
This is kind of a hack. I wonder if we can get other types of candidates that are the same except for bound vars. This won't be a problem with Chalk, since we don't really need to know that there are two different "candidates" if they both give the same final substitution.
r? `@nikomatsakis`
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.
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.
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
That PR caused multiple test failures when Rust's channel is changed
from nightly to anything else. The commit will have to be landed again
after the test suite is fixed.
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.
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.
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 as well
Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar
Howdy,
This PR does the following:
1. Updates the grammar of a comment in librustdoc.
2. Replaces a few write!(..\n) macros with writeln!(..\n) for clarity. (Please let me know if there is a reason why this might be wrong!)
Best,
Mautamu
Replace 'NULL' with 'null'
This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
Do not print visibility in external traits
This PR fixes the bug that caused traits, which were re-exported, having visibility modifiers in front of methods, which is invalid.
It would be nice to add a test for this, but I don't even know if tests with multiple crates are possible.
Resolves#81274
