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`.
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.
Rollup of 4 pull requests
Successful merges:
- #91169 (Change cg_ssa's get_param to borrow the builder mutably)
- #91176 (If the thread does not get the lock in the short term, yield the CPU)
- #91212 (Fix ICE due to out-of-bounds statement index when reporting borrowck error)
- #91225 (Fix invalid scrollbar display on source code page)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix ICE due to out-of-bounds statement index when reporting borrowck error
Replace an `[index]` with a `.get` when `statement_index` points to a basic-block terminator (and is therefore out-of-bounds in the statements list).
Fixes#91206
Cc ``@camsteffen``
r? ``@oli-obk``
If the thread does not get the lock in the short term, yield the CPU
Reduces on [RustyHermit](https://github.com/hermitcore/rusty-hermit) the amount of wasted processor cycles
Change cg_ssa's get_param to borrow the builder mutably
This is a small change to make `get_param` more flexible for codegens that may need to modify things when retrieving function parameters.
This will currently only be used by [rustc_codegen_nvvm](https://github.com/Rust-GPU/Rust-CUDA) (my own project), but may be useful to more codegens in the future.
This is needed because cg_nvvm needs to remap certain types to libnvvm-friendly types, such as `i128` -> `<2 x i64>`. Because cg_ssa does not give mutable access to the builder, i resorted to using a mutex:
```rs
fn get_param(&self, index: usize) -> Self::Value {
let val = llvm::get_param(self.llfn(), index as c_uint);
trace!("Get param `{:?}`", val);
unsafe {
let llfnty = LLVMRustGetFunctionType(self.llfn());
let map = self.remapped_integer_args.borrow();
if let Some((_, key)) = map.get(llfnty) {
if let Some((_, new_ty)) = key.iter().find(|t| t.0 == index) {
trace!("Casting irregular param {:?} to {:?}", val, new_ty);
return transmute_llval(
*self.llbuilder.lock().unwrap(),
&self.cx,
val,
*new_ty,
);
}
}
val
}
}
```
However, i predict this is pretty bad for performance, considering how much builders are called during codegen, so i would greatly appreciate having a more flexible API for this.
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`.
Fix stack overflow in `usefulness.rs`
Fix#88747
Applied the suggestion from `@nbdd0121,` not sure if this has any drawbacks. The first call to `ensure_sufficient_stack` is not needed to fix the test case, but I added it to be safe.
Visit `param_env` field in Obligation's `TypeFoldable` impl
This oversight appears to have gone unnoticed for a long time
without causing issues, but it should still be fixed.
The current implementation is much more conservative than it needs to
be, because it's dealing with the size and alignment of a given `T`,
which are more restricted than an arbitrary `Layout`.
For example, imagine a struct with a `u32` and a `u4`. You can safely
create a `Layout { size_: 5, align_: 4 }` by hand, but
`Layout:🆕:<T>` will give `Layout { size_: 8, align_: 4}`, where the
size already has padding that accounts for the alignment. (And the
existing `debug_assert_eq!` in `Layout::array` already demonstrates that
no additional padding is required.)
Improve rustdoc-gui CI
As commented [here](https://github.com/rust-lang/rust/pull/91179#discussion_r756023009):
When the text isn't displayed, the color returned by puppeteer is always `rgba(0,0,0,0)`, which is definitely not the right value. To prevent this error from happening again, `browser-ui-test` will now fail if a CSS color check is run when the text isn't displayed.
Either this PR or #91179 is merged first, they'll conflict because I made changes to the same test file.
cc `@jyn514`
r? `@jsha`
Diagnostic tweaks
* On type mismatch caused by assignment, point at the source of the expectation
* Hide redundant errors
* Suggest `while let` when `let` is missing in some cases
I would like to rename it to `Type::Path`, but then it can't be
re-exported since the name would conflict with the `Path` struct.
Usually enum variants are referred to using their qualified names in
Rust (and parts of rustdoc already do that with `clean::Type`), so this
is also more consistent with the language.
* Do not emit unnecessary E0308 after E0070
* Show fewer errors on `while let` missing `let`
* Hide redundant E0308 on `while let` missing `let`
* Point at binding definition when possible on invalid assignment
* do not point at closure twice
* do not suggest `if let` for literals in lhs
* account for parameter types
