PassWrapper: update for LLVM change D102093
In https://reviews.llvm.org/D102093 lots of things stopped taking the
DebugLogging boolean parameter. Mercifully we appear to always set
DebugPassManager to false, so I don't think we're losing anything by not
passing this parameter.
Windows implementation of feature `path_try_exists`
Draft of a Windows implementation of `try_exists` (#83186).
The first commit reorganizes the code so I would be interested to get some feedback on if this is a good idea or not. It moves the `Path::try_exists` function to `fs::exists`. leaving the former as a wrapper for the latter. This makes it easier to provide platform specific implementations and matches the `fs::metadata` function.
The other commit implements a Windows specific variant of `exists`. I'm still figuring out my approach so this is very much a first draft. Eventually this will need some more eyes from knowledgable Windows people.
Always produce sub-obligations when using cached projection result
See https://github.com/rust-lang/rust/issues/85360
When we skip adding the sub-obligations to the `obligation` list, we can affect whether or not the final result is `EvaluatedToOk` or `EvaluatedToOkModuloObligations`. This creates problems for incremental compilation, since the projection cache is untracked shared state.
To solve this issue, we unconditionally process the sub-obligations. Surprisingly, this is a slight performance *win* in many cases.
std: Don't inline TLS accessor on MinGW
This is causing [issues] on Cargo's own CI for MinGW and given the
original investigation there's no reason that MinGW should work when
MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception.
[issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
Prevent tab title to "null" if the URL is a search one
When we arrive on page with a search parameter in the URL, until the results are displayed, the page title is "null". It's because of this code:
```js
if (params.search !== undefined) {
var search = searchState.outputElement();
search.innerHTML = "<h3 style=\"text-align: center;\">" +
searchState.loadingText + "</h3>";
searchState.showResults(search);
loadSearch();
}
```
In `searchState.showResults`, we have this:
```js
document.title = searchState.title;
```
But since it's `null`, we set it as title. This PR fixes it.
r? `@jsha`
Fix missing lifetimes diagnostics after #83759
In #83759 while rebasing I didn't realize there was a new function for suggesting to add lifetime arguments. It relied on some invariants, namely that if a generic type/trait has angle brackets then it must have some generic argument, which is now no longer true. This PR updates that function to handle the new invariants.
This also adds a new regression test but I'm not sure if that's the correct place for it.
Fixes#85347
Move `std::memchr` to `sys_common`
`std::memchr` is a thin abstraction over the different `memchr` implementations in `sys`, along with documentation and tests. The module is only used internally by `std`, nothing is exported externally. Code like this is exactly what the `sys_common` module is for, so this PR moves it there.
Update list of allowed aarch64 features
I recently added these features to std_detect for aarch64 linux, pending [review](https://github.com/rust-lang/stdarch/pull/1146).
I have commented any features not supported by LLVM 9, the current minimum version for Rust. Some (PAuth at least) were renamed between 9 & 12 and I've left them disabled. TME, however, is not in LLVM 9 but I've left it enabled.
See https://github.com/rust-lang/stdarch/issues/993
Rollup of 8 pull requests
Successful merges:
- #84717 (impl FromStr for proc_macro::Literal)
- #85169 (Add method-toggle to <details> for methods)
- #85287 (Expose `Concurrent` (private type in public i'face))
- #85315 (adding time complexity for partition_in_place iter method)
- #85439 (Add diagnostic item to `CStr`)
- #85464 (Fix UB in documented example for `ptr::swap`)
- #85470 (Fix invalid CSS rules for a:hover)
- #85472 (CTFE Machine: do not expose Allocation)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Introduce `sys_common::rt::rtprintpanic!` to replace `sys_common::util` functionality
This PR introduces a new macro `rtprintpanic!`, similar to `sys_common::util::dumb_print` and uses that macro to replace all `sys_common::util` functionality.
Avoid zero-length memcpy in formatting
This has two separate and somewhat orthogonal commits. The first change adjusts the ToString general impl for all types that implement Display; it no longer uses the full format machinery, rather directly falling onto a `std::fmt::Display::fmt` call. The second change directly adjusts the general core::fmt::write function which handles the production of format_args! to avoid zero-length push_str calls.
Both changes target the fact that push_str will still call memmove internally (or a similar function), as it doesn't know the length of the passed string. For zero-length strings in particular, this is quite expensive, and even for very short (several bytes long) strings, this is also expensive. Future work in this area may wish to have us fallback to write_char or similar, which may be cheaper on the (typically) short strings between the interpolated pieces in format_args!.
CTFE Machine: do not expose Allocation
`Memory` is careful now to not expose direct access to `Allocation`, but this one slipped through.
r? ``@oli-obk``
adding time complexity for partition_in_place iter method
I feel that one thing missing from rust docs compared to cpp references is existence of time complexity for all methods and functions. While it would be humongous task to include it for everything in single go, it is still doable if we as community keep on adding it in relevant places as and when we find them.
This PR adds the time complexity for partition_in_place method in iter.
Expose `Concurrent` (private type in public i'face)
#53410 introduced experimental support for custom test frameworks.
Such frameworks may wish to build upon `library/test` by calling into its publicly exposed API (which I entirely understand is wholly unstable). However, any that wish to call `test::run_test` cannot currently do so because `test::options::Concurrent` (the type of its `concurrent` parameter) is not publicly exposed.
impl FromStr for proc_macro::Literal
Note that unlike `impl FromStr for proc_macro::TokenStream`, this impl does not permit whitespace or comments. The input string must consist of nothing but your literal.
- `"1".parse::<Literal>()` ⟶ ok
- `"1.0".parse::<Literal>()` ⟶ ok
- `"'a'".parse::<Literal>()` ⟶ ok
- `"\"\n\"".parse::<Literal>()` ⟶ ok
- `"0 1".parse::<Literal>()` ⟶ LexError
- `" 0".parse::<Literal>()` ⟶ LexError
- `"0 ".parse::<Literal>()` ⟶ LexError
- `"/* comment */0".parse::<Literal>()` ⟶ LexError
- `"0/* comment */".parse::<Literal>()` ⟶ LexError
- `"0// comment".parse::<Literal>()` ⟶ LexError
---
## Use case
```rust
let hex_int: Literal = format!("0x{:x}", int).parse().unwrap();
```
The only way this is expressible in the current API is significantly worse.
```rust
let hex_int = match format!("0x{:x}", int)
.parse::<TokenStream>()
.unwrap()
.into_iter()
.next()
.unwrap()
{
TokenTree::Literal(literal) => literal,
_ => unreachable!(),
};
```
remove InPlaceIterable marker from Peekable due to unsoundness
The unsoundness is not in Peekable per se, it rather is due to the
interaction between Peekable being able to hold an extra item
and vec::IntoIter's clone implementation shortening the allocation.
An alternative solution would be to change IntoIter's clone implementation
to keep enough spare capacity available.
fixes#85322
std: Attempt again to inline thread-local-init across crates
Issue #25088 has been part of `thread_local!` for quite some time now.
Historical attempts have been made to add `#[inline]` to `__getit`
in #43931, #50252, and #59720, but these attempts ended up not landing
at the time due to segfaults on Windows.
In the interim though with `const`-initialized thread locals AFAIK this
is the only remaining bug which is why you might want to use
`#[thread_local]` over `thread_local!`. As a result I figured it was
time to resubmit this and see how it fares on CI and if I can help
debugging any issues that crop up.
Closes#25088
