Update chalk to 0.75.0
- Compute flags in `intern_ty`
- Remove `tracing-serde` from `PERMITTED_DEPENDENCIES`
- Bump `tracing-tree` to 0.2.0
- Bump `tracing-subscriber` to 0.3.3
Use panic() instead of panic!() in some places in core.
See https://github.com/rust-lang/rust/pull/92068 and https://github.com/rust-lang/rust/pull/92140.
This avoids the `panic!()` macro in a few potentially hot paths. This becomes more relevant when switching `core` to Rust 2021, as it'll avoid format_args!() and save some compilation time. (It doesn't make a huge difference, but still.) (Also the errors in const panic become slightly nicer.)
Quote bat script command line
Fixes#91991
[`CreateProcessW`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw#parameters) should only be used to run exe files but it does have some (undocumented) special handling for files with `.bat` and `.cmd` extensions. Essentially those magic extensions will cause the parameters to be automatically rewritten. Example pseudo Rust code (note that `CreateProcess` starts with an optional application name followed by the application arguments):
```rust
// These arguments...
CreateProcess(None, `@"foo.bat` "hello world""`@,` ...);
// ...are rewritten as
CreateProcess(Some(r"C:\Windows\System32\cmd.exe"), `@""foo.bat` "hello world"""`@,` ...);
```
However, when setting the first parameter (the application name) as we now do, it will omit the extra level of quotes around the arguments:
```rust
// These arguments...
CreateProcess(Some("foo.bat"), `@"foo.bat` "hello world""`@,` ...);
// ...are rewritten as
CreateProcess(Some(r"C:\Windows\System32\cmd.exe"), `@"foo.bat` "hello world""`@,` ...);
```
This means the arguments won't be passed to the script as intended.
Note that running batch files this way is undocumented but people have relied on this so we probably shouldn't break it.
Don't emit shared files when scraping examples from dependencies in Rustdoc
This PR fixes#91605. The issue is that `Context::init` gets called when scraping dependencies. By default, just calling `init` calls into `write_shared` and `build_index` which register the scraped crate into a list that later gets used for the Rustdoc sidebar. The fix is to ensure that `write_shared` is not called when scraping.
r? `@jyn514`
Change Backtrace::enabled atomic from SeqCst to Relaxed
This atomic is not synchronizing anything outside of its own value, so we don't need the `Acquire`/`Release` guarantee that all memory operations prior to the store are visible after the subsequent load, nor the `SeqCst` guarantee of all threads seeing all of the sequentially consistent operations in the same order.
Using `Relaxed` reduces the overhead of `Backtrace::capture()` in the case that backtraces are not enabled.
## Benchmark
```rust
#![feature(backtrace)]
use std::backtrace::Backtrace;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::thread;
use std::time::Instant;
fn main() {
let begin = Instant::now();
let mut threads = Vec::new();
for _ in 0..64 {
threads.push(thread::spawn(|| {
for _ in 0..10_000_000 {
let _ = Backtrace::capture();
static LOL: AtomicUsize = AtomicUsize::new(0);
LOL.store(1, Ordering::Release);
}
}));
}
for thread in threads {
let _ = thread.join();
}
println!("{:?}", begin.elapsed());
}
```
**Before:** 6.73 seconds
**After:** 5.18 seconds
Add some JSDoc comments to rustdoc JS
This follows the Closure Compiler dialect of JSDoc, so we can use it to do some basic type checking. We don't plan to compile with Closure Compiler, just use it to check types. See https://github.com/google/closure-compiler/wiki/ for details.
To try checking the annotations, run:
```
npm i -g google-closure-compiler
google-closure-compiler -W VERBOSE build/x86_64-unknown-linux-gnu/doc/{search-index1.59.0.js,crates1.59.0.js} src/librustdoc/html/static/js/{search.js,main.js,storage.js} --externs src/librustdoc/html/static/js/externs.js >/dev/null
```
You'll see some warnings that "String continuations are not recommended". I'm not addressing those right now.
[Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/doc.20format.20for.20JS/near/265209466).
r? `@GuillaumeGomez`
Fix duplicate derive clone suggestion
closes https://github.com/rust-lang/rust/issues/91492
The addition of:
```rust
derives.sort();
derives.dedup();
```
is what actually solves the problem.
The rest is just cleanup.
I want to improve the diagnostic message to provide the suggestion as a proper diff but ran into some problems, so I'll attempt that again in a follow up PR.
Allow reverse iteration of lowercase'd/uppercase'd chars
The PR implements `DoubleEndedIterator` trait for `ToLowercase` and `ToUppercase`.
This enables reverse iteration of lowercase/uppercase variants of character sequences.
One of use cases: determining whether a char sequence is a suffix of another one.
Example:
```rust
fn endswith_ignore_case(s1: &str, s2: &str) -> bool {
for eob in s1
.chars()
.flat_map(|c| c.to_lowercase())
.rev()
.zip_longest(s2.chars().flat_map(|c| c.to_lowercase()).rev())
{
match eob {
EitherOrBoth::Both(c1, c2) => {
if c1 != c2 {
return false;
}
}
EitherOrBoth::Left(_) => return true,
EitherOrBoth::Right(_) => return false,
}
}
true
}
```
This follows the Closure Compiler dialect of JSDoc, so we
can use it to do some basic type checking. We don't plan to
compile with Closure Compiler, just use it to check types. See
https://github.com/google/closure-compiler/wiki/ for details.
Fix failing tests
Fixes tests that have been failing in CI.
I hope it's ok but I've temporarily commented out some of the Windows resolver tests. I actually have a bigger fix for that test code as part of another PR. I could separate it out and patch as necessary but I'd prefer not to rush into that if possible.
r? `@Mark-Simulacrum`
Sync rustc_codegen_cranelift
The main highlight this sync is improved support for inline assembly. Thanks `@nbdd0121!` Inline assembly is still disabled by default for builds in the main rust repo though. Cranelift will now also be built from the crates.io releases rather than the git repo. Git repos are incompatible with vendoring.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Move duplicates removal when generating results instead of when displaying them
Currently, we store 200 results per tab and then display them. However, it was possible to have duplicates which is why we have this check. However, instead of doing it when displaying the results, it's much better instead to do it even before to simplify the display part a bit.
r? `@jsha`
Improve suggestions for importing out-of-scope traits reexported as `_`
1. Fix up the `parent_map` query to prefer visible parents that _don't_ export items with the name `_`.
* I'm not sure if I modified this query properly. Not sure if we want to check for other idents than `kw::Underscore`.
* This also has the side-effect of not doing BFS on any modules re-exported as `_`, but I think that's desirable here too (or else we get suggestions for paths like `a::_::b` like in [this doctest example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d9505ea45bb80adf40bb991298f952be)).
2. Bail in `try_print_visible_def_path` if the `def_id` is re-exported as `_`, which will fall back to printing the def-id's real (definition) path.
* Side-effect of this is that we print paths that are not actually public, but it seems we already sometimes suggest `use`ing paths that are private anyways. See [this doctest example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bad513ed3241f8ff87579eed8046ad10) for demonstration of current behavior.
3. Suggest a glob-import (for example `my_library::prelude::*`) if the trait in question is only pub-exported as `_`, as a fallback.
```
use foo::bar::prelude::*; // trait MyTrait
```
* I think this is good fallback behavior to suggest instead of doing nothing. Thanks to the original issue filer for suggesting this.
I was somewhat opinionated about behaviors in this PR, and I'm totally open to limiting the impact of my changes or only landing parts of this. Happy to receive feedback if there are better ways to the same end.
Fixes#86035
Implement StableHash for BitSet and BitMatrix via Hash
This fixes an issue where bit sets / bit matrices the same word
content but a different domain size would receive the same hash.
