Fix ICE when lowering `trait A where for<'a> Self: 'a`
Fixes#88586.
r? `@jackh726`
Jack, this fix is much smaller in scope than what I think you were proposing in the issue. Let me know if you had a vision for a larger refactor here.
cc `@JohnTitor`
Perform Sync check on static items in wf-check instead of during const checks
r? `@RalfJung`
This check is solely happening on the signature of the static item and not on its body, therefor it belongs into wf-checking instead of const checking.
Make `TypeFolder::fold_*` return `Result`
Implements rust-lang/compiler-team#432.
Initially this is just a rebase of `@LeSeulArtichaut's` work in #85469 (abandoned; see https://github.com/rust-lang/rust/pull/85485#issuecomment-908781112). At that time, it caused a regression in performance that required some further exploration... with this rebased PR bors can hopefully report some perf analysis from which we can investigate further (if the regression is indeed still present).
r? `@jackh726` cc `@nikomatsakis`
Only check for errors in predicate when skipping impl assembly
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Stabilize some `MaybeUninit` behavior as const
This stabilizes the `MaybeUninit::as_ptr`, `MaybeUninit::assume_init`, and `MaybeUninit::assume_init_ref` as `const fn`. `MaybeUninit::as_mut_ptr` has been moved to a new flag: `const_maybe_uninit_as_mut_ptr`, which is blocked on #57349. `MaybeUninit::slice_assume_init_ref` can be `const fn` when the method is stabilized in general.
The relevant intrinsic has been stabilized as `const` as well, though this isn't user-visible. Due to the seemingly unrelated feature name I performed `rg const_assert_type` and found no other instances of it being used.
r? `@oli-obk`
`@rustbot` label: +A-const-fn +S-waiting-on-review +T-libs-api
Eliminate an unreachable codepath from String::from_utf8_lossy
`Utf8Lossy`'s `Iterator` implementation ensures that only the **final** chunk has an empty slice for `broken`:
dd549dcab4/library/core/src/str/lossy.rs (L46-L47)
Thus the only way the **first** chunk could have an empty `broken` is if it is the **final** chunk, i.e. there is only one chunk total. And the only way that there could be one chunk total with an empty `broken` is if the whole input is valid utf8 and non-empty.
That condition has already been handled by an early return, so at the point that the first `REPLACEMENT` is being pushed, it's impossible for `first_broken` to be empty.
Prior to PR #91205, checking for errors in the overall obligation
would check checking the `ParamEnv`, due to an incorrect
`super_visit_with` impl. With this bug fixed, we will now
bail out of impl candidate assembly if the `ParamEnv` contains
any error types.
In practice, this appears to be overly conservative - when an error
occurs early in compilation, we end up giving up early for some
predicates that we could have successfully evaluated without overflow.
By only checking for errors in the predicate itself, we avoid causing
additional spurious 'type annotations needed' errors after a 'real'
error has already occurred.
With this PR, the diagnostic changes caused by PR #91205 are reverted.
Fix Iterator::advance_by contract inconsistency
The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n.
It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator.
These statements are inconsistent.
Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too.
While adding some tests I also found a bug in `Take::advance_back_by`.
Account for incorrect `where T::Assoc = Ty` bound
Provide suggestoin to constrain trait bound for associated type.
Revert incorrect changes to `missing-bounds` test.
Address part of #20041.
rustdoc: Consolidate static-file replacement mechanism
There were a few places in rustdoc where we would take static JS or CSS and rewrite it at doc generation time to insert values. This consolidates all the CSS instances into one CSS file and replaces the JS examples with data- attributes on the rustdoc-vars div.
Demo https://rustdoc.crud.net/jsha/static-file-replace/test_docs/
r? ``@GuillaumeGomez``
Expand `available_parallelism` docs in anticipation of cgroup quota support
The "fixed" in "fixed steady state limits" means to exclude load-dependent resource prioritization
that would calculate to 100% of capacity on an idle system and less capacity on a loaded system.
Additionally I also exclude "system load" since it would be silly to try to identify
other, perhaps higher priority, processes hogging some CPU cores that aren't explicitly excluded
by masks/quotas/whatever.
Document non-guarantees for Hash
Dependence on endianness and type sizes was reported for enum discriminants in #74215 but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.
## Question
Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`?
resolves#74215
Weaken guarantee around advancing underlying iterators in zip
The current guarantee (introduced in #52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this.
This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()`
because removing it would also affect `next_back()` in more surprising ways.
The intent is to be able to remove for example this branch
36bcf40697/library/core/src/iter/adapters/zip.rs (L234-L243)
or this test
36bcf40697/library/core/tests/iter/adapters/zip.rs (L177-L188)
Solves #82303 by declaring it a non-issue.
Refactor weak symbols in std::sys::unix
This makes a few changes to the weak symbol macros in `sys::unix`:
- `dlsym!` is added to keep the functionality for runtime `dlsym`
lookups, like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't
want to show up in ELF symbol tables.
- `weak!` now uses `#[linkage = "extern_weak"]` symbols, so its runtime
behavior is just a simple null check. This is also used by `syscall!`.
- On non-ELF targets (macos/ios) where that linkage is not known to
behave, `weak!` is just an alias to `dlsym!` for the old behavior.
- `raw_syscall!` is added to always call `libc::syscall` on linux and
android, for cases like `clone3` that have no known libc wrapper.
The new `weak!` linkage does mean that you'll get versioned symbols if
you build with a newer glibc, like `WEAK DEFAULT UND statx@GLIBC_2.28`.
This might seem problematic, but old non-weak symbols can tie the build
to new versions too, like `dlsym@GLIBC_2.34` from their recent library
unification. If you build with an old glibc like `dist-x86_64-linux`
does, you'll still get unversioned `WEAK DEFAULT UND statx`, which may
be resolved based on the runtime glibc.
I also found a few functions that don't need to be weak anymore:
- Android can directly use `ftruncate64`, `pread64`, and `pwrite64`, as
these were added in API 12, and our baseline is API 14.
- Linux can directly use `splice`, added way back in glibc 2.5 and
similarly old musl. Android only added it in API 21 though.
Remove `--display-doctest-warnings`
`--display-doctest-warnings` can be replicated in full with other existing features, there's no
need to have a separate option for it. This removes the option and documents the combination of other features to replicate it.
This also fixes a bug where `--test-args=--show-output` had no effect.
cc `@ollie27,` https://github.com/rust-lang/rust/pull/73314#issuecomment-668317262
Fixes https://github.com/rust-lang/rust/issues/41574
r? `@GuillaumeGomez`
Fix bug where submodules wouldn't be updated when running x.py from a subdirectory
Previously, it would concatenate the relative path to the current
subdirectory, which looked at the wrong folder.
I tested this by checking out `1.56.1`, changing the current directory
to `src/`, and running `../x.py build`.
Fixes https://github.com/rust-lang/rust/issues/90481 (cc `@pnkfelix).`
r? `@Mark-Simulacrum`
Saner formatting for UTF8_CHAR_WIDTH table
The way these lines were currently wrapped definitely does not look like someone's intentional formatting. It's likely they got disfigured by rustfmt at some point.
This commit rearranges it to a rustfmt-compatible formatting that I find easier to read.
rustdoc: Rename `Type::ResolvedPath` to `Type::Path` and don't re-export it
The new name is shorter, simpler, and consistent with `hir::Ty`. It can't be
re-exported since the name would conflict with the `clean::Path` struct. But
usually enum variants are referred to using their qualified names in Rust anyway
(and parts of rustdoc already do that with `clean::Type`), so this is also more
consistent with the language.
r? `@GuillaumeGomez`
cc `@jyn514`
Fix another ICE in rustdoc scrape_examples
This has occurred to me when documenting a crate with the arguments. Not sure what could have caused it.
r? `@willcrichton`
Faster `Layout::array`
`Layout::array` is called (indirectly) by `Vec::push()`, which is typically instantiated many times, and so making it smaller can help with compile times because less LLVM IR is generated.
r? `@ghost`
This can be replicated in full with other existing features, there's no
need to have a separate option for it.
This also fixes a bug where `--test-args=--show-output` had no effect,
and updates the documentation.
