bors [Thu, 23 Dec 2021 08:59:55 +0000 (08:59 +0000)]
Auto merge of #92167 - pierwill:chalk-update, r=jackh726
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
bors [Thu, 23 Dec 2021 05:17:47 +0000 (05:17 +0000)]
Auto merge of #92155 - m-ou-se:panic-fn, r=eddyb
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.)
Matthias Krüger [Wed, 22 Dec 2021 23:28:56 +0000 (00:28 +0100)]
Rollup merge of #92208 - ChrisDenton:win-bat-cmd, r=dtolnay
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.
Matthias Krüger [Wed, 22 Dec 2021 23:28:55 +0000 (00:28 +0100)]
Rollup merge of #92146 - willcrichton:example-analyzer, r=jyn514
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.
Matthias Krüger [Wed, 22 Dec 2021 23:28:54 +0000 (00:28 +0100)]
Rollup merge of #92139 - dtolnay:backtrace, r=m-ou-se
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());
}
```
This PR adds `std::sys::solid::fs::File::read_buf` to catch up with the changes introduced by #81156 and fix the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets..
Matthias Krüger [Wed, 22 Dec 2021 23:28:52 +0000 (00:28 +0100)]
Rollup merge of #92026 - jsha:jsdoc-search, r=GuillaumeGomez
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.
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.
Matthias Krüger [Wed, 22 Dec 2021 23:28:51 +0000 (00:28 +0100)]
Rollup merge of #88858 - spektom:to_lower_upper_rev, r=dtolnay
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.
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.
Aaron Hill [Wed, 22 Dec 2021 19:35:17 +0000 (14:35 -0500)]
Store a `DefId` instead of an `AdtDef` in `AggregateKind::Adt`
The `AggregateKind` enum ends up in the final mir `Body`. Currently,
any changes to `AdtDef` (regardless of how significant they are)
will legitimately cause the overall result of `optimized_mir` to change,
invalidating any codegen re-use involving that mir.
This will get worse once we start hashing the `Span` inside `FieldDef`
(which is itself contained in `AdtDef`).
To try to reduce these kinds of invalidations, this commit changes
`AggregateKind::Adt` to store just the `DefId`, instead of the full
`AdtDef`. This allows the result of `optimized_mir` to be unchanged
if the `AdtDef` changes in a way that doesn't actually affect any
of the MIR we build.
bors [Wed, 22 Dec 2021 19:21:25 +0000 (19:21 +0000)]
Auto merge of #92201 - ChrisDenton:fix-tests, r=Mark-Simulacrum
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.
RawVec: don't recompute capacity after allocating.
Currently it sets the capacity to `ptr.len() / mem::size_of::<T>()`
after any buffer allocation/reallocation. This would be useful if
allocators ever returned a `NonNull<[u8]>` with a size larger than
requested. But this never happens, so it's not useful.
Removing this slightly reduces the size of generated LLVM IR, and
slightly speeds up the hot path of `RawVec` growth.
bors [Tue, 21 Dec 2021 09:01:25 +0000 (09:01 +0000)]
Auto merge of #92152 - matthiaskrgr:rollup-nmskpw6, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #90345 (Stabilise entry_insert)
- #91412 (Improve suggestions for importing out-of-scope traits reexported as `_`)
- #91770 (Suggest adding a `#[cfg(test)]` to to a test module)
- #91823 (Make `PTR::as_ref` and similar methods `const`.)
- #92127 (Move duplicates removal when generating results instead of when displaying them)
- #92129 (JoinHandle docs: add missing 'the')
- #92131 (Sync rustc_codegen_cranelift)
Matthias Krüger [Tue, 21 Dec 2021 07:33:43 +0000 (08:33 +0100)]
Rollup merge of #92131 - bjorn3:sync_cg_clif-2021-12-20, r=bjorn3
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.
Matthias Krüger [Tue, 21 Dec 2021 07:33:41 +0000 (08:33 +0100)]
Rollup merge of #92127 - GuillaumeGomez:search-results-duplicate-removal, r=jsha
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.
Matthias Krüger [Tue, 21 Dec 2021 07:33:37 +0000 (08:33 +0100)]
Rollup merge of #91412 - compiler-errors:issue-86035, r=oli-obk
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.
bors [Mon, 20 Dec 2021 04:21:12 +0000 (04:21 +0000)]
Auto merge of #91900 - pitaj:fix-91714, r=jyn514
rustdoc: make `--passes` and `--no-defaults` have no effect
Fixes #91714
One potential issue is that currently there is no stable way to achieve `--document-hidden-items`. This affects test `issue-15347`.
I also had to modify the tests `issue-42875` and `no-compiler-export`. Regardless of combinations of `--document-hidden-items` and `--document-private-items`, I was unable to get these to pass without the modifications. I left behind a comment noting the change.
vacuus [Sun, 19 Dec 2021 02:54:59 +0000 (21:54 -0500)]
Omit check of a successive line in loop
I think that s == "" is the only edge case (as it makes iter.next() return None the first time). The early return is necessary so that the last character of 'out' isn't popped if s == "" && !frag.need_backline
bors [Sun, 19 Dec 2021 17:14:12 +0000 (17:14 +0000)]
Auto merge of #92106 - matthiaskrgr:rollup-zw6t1mu, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #91791 (Fix an ICE when lowering a float with missing exponent magnitude)
- #91878 (Remove `in_band_lifetimes` from `rustc_infer`)
- #91895 (Remove `in_band_lifetimes` for `rustc_monomorphize`)
- #92029 (Explicitly set no ELF flags for .rustc section)
Matthias Krüger [Sun, 19 Dec 2021 16:38:35 +0000 (17:38 +0100)]
Rollup merge of #92029 - nikic:section-flags-fix, r=davidtwco
Explicitly set no ELF flags for .rustc section
For a data section, the object crate will set the SHF_ALLOC by default, which is exactly what we don't want. Explicitly set sh_flags to zero to avoid this.
I checked with `objdump -h` that this produces the right flags for ELF.
Matthias Krüger [Sun, 19 Dec 2021 16:38:33 +0000 (17:38 +0100)]
Rollup merge of #91878 - LegionMammal978:less-inband-infer, r=Aaron1011
Remove `in_band_lifetimes` from `rustc_infer`
See #91867 for more information.
This crate actually had a typo `'ctx` in one of its functions:
```diff
-pub fn same_type_modulo_infer(a: Ty<'tcx>, b: Ty<'ctx>) -> bool {
+pub fn same_type_modulo_infer<'tcx>(a: Ty<'tcx>, b: Ty<'tcx>) -> bool {
```
Also, I wasn't entirely sure about the lifetimes in `suggest_new_region_bound`:
```diff
pub fn suggest_new_region_bound(
- tcx: TyCtxt<'tcx>,
+ tcx: TyCtxt<'_>,
err: &mut DiagnosticBuilder<'_>,
fn_returns: Vec<&rustc_hir::Ty<'_>>,
```
Should all of those lifetimes really be distinct?
Matthias Krüger [Sun, 19 Dec 2021 09:45:55 +0000 (10:45 +0100)]
Rollup merge of #92077 - jyn514:remove-collapsed, r=GuillaumeGomez
rustdoc: Remove unused `collapsed` field
`render/context` always runs after `run_global_context`, so it was always set to `true`.
This is a holdover from when rustdoc allowed configuring passes, but the `collapse-docs` pass was
removed ages ago, and the ability to configure passes is about to be removed.
Found while reviewing https://github.com/rust-lang/rust/pull/91305.
Matthias Krüger [Sun, 19 Dec 2021 09:45:54 +0000 (10:45 +0100)]
Rollup merge of #92071 - ajtribick:patch-1, r=the8472
Update example code for Vec::splice to change the length
The current example for `Vec::splice` illustrates the replacement of a section of length 2 with a new section of length 2. This isn't a particularly interesting case for splice, and makes it look a bit like a shorthand for the kind of manipulations that could be done with a mutable slice.
In order to provide a stronger example, this updates the example to use different lengths for the source and destination regions, and uses a slice from the middle of the vector to illustrate that this does not necessarily have to be at the beginning or the end.
Matthias Krüger [Sun, 19 Dec 2021 09:45:53 +0000 (10:45 +0100)]
Rollup merge of #92042 - ChrisDenton:msvc-static-tls, r=nagisa
Enable `#[thread_local]` for all windows-msvc targets
As it stands, `#[thread_local]` is enabled haphazardly for msvc. It seems all 64-bit targets have it enabled, but not 32-bit targets unless they're also UWP targets (perhaps because UWP was added more recently?). So this PR simply enables it for 32-bit targets as well. I can't think of a reason not to and I've confirmed by running tests locally which pass.