Noah Lev [Tue, 28 Dec 2021 02:53:00 +0000 (18:53 -0800)]
rustdoc: Remove some unnecessary `cache` parameters
Based on
https://github.com/rust-lang/rust/pull/80883#issuecomment-774437832.
The `tcx` parameters do seem to be used though, so I only removed the
`cache` parameters.
bors [Mon, 27 Dec 2021 21:55:52 +0000 (21:55 +0000)]
Auto merge of #92329 - matthiaskrgr:rollup-l3b4fl1, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #90586 (Relax priv-in-pub lint on generic bounds and where clauses of trait impls.)
- #92112 (Fix the error of checking `base_expr` twice in type_changing_struct_update)
- #92147 (rustc_builtin_macros: make asm mod public for rustfmt)
- #92161 (resolve: Minor miscellaneous cleanups from #89059)
- #92264 (Remove `maybe_uninit_extra` feature from Vec docs)
- #92303 (Add test cases for issue #26186)
- #92307 (Fix minor typos)
Matthias Krüger [Mon, 27 Dec 2021 20:42:29 +0000 (21:42 +0100)]
Rollup merge of #92303 - Patrick-Poitras:issue-26186, r=jackh726
Add test cases for issue #26186
Closes #26186
It seems that issue #26186 has been solved at some point since the issue has been last updated. I've merged together the examples that were supplied by `@Osspial,` `@Mark-Simulacrum,` `@Diggsey,` `@eefriedman` and `@shepmaster,` so that we can add this to the testing suite and prevent these issues from re-occurring.
Matthias Krüger [Mon, 27 Dec 2021 20:42:25 +0000 (21:42 +0100)]
Rollup merge of #90586 - jswrenn:relax-privacy-lints, r=petrochenkov
Relax priv-in-pub lint on generic bounds and where clauses of trait impls.
The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls.
## Current Behavior
On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // ERROR
{}
```
...and it's a **warning** to have have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
impl Trait for Type
where
Pub: Priv // WARNING
{}
```
This lint applies to `where` clauses in other contexts, too; e.g. on free functions:
```rust
struct Priv<T>(T);
pub trait Pub {}
impl<T: Pub> Pub for Priv<T> {}
pub fn function<T>()
where
Priv<T>: Pub // WARNING
{}
```
**These constraints could be relaxed without issue.**
## New Behavior
This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait:
```rust
pub trait Trait {}
pub struct Type {}
struct Priv {}
impl Trait for Priv {}
impl Trait for Type
where
Priv: Trait // OK
{}
```
...and it's okay to have a public type constrained by a private trait:
```rust
pub trait Trait {}
pub struct Type {}
## Rationale
While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context:
```rust
fn callsite<T>()
where
Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too
{
function::<T>()
}
```
...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful.
However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait:
```rust
mod upstream {
pub trait Trait {
fn method(&self) {}
}
pub struct Type<T>(T);
impl<T> Trait for Type<T>
where
Pub<T>: Priv // WARNING
{}
}
mod downstream {
use super::upstream::*;
fn function<T>(value: Type<T>)
where
Type<T>: Trait // <- no private deets!
{
value.method();
}
}
```
**This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless.
## Other Notes
- See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397).
- This PR effectively reverts #79291.
bors [Sat, 25 Dec 2021 14:47:12 +0000 (14:47 +0000)]
Auto merge of #92227 - Kobzol:rustdoc-doc-hidden, r=jyn514
Rustdoc: use `is_doc_hidden` method on more places
While profiling `rustdoc`, I noticed that finding out if some item is marked with `#[doc(hidden)]` is relatively hot, so I tried to optimize it.
I noticed that there is already a method called `is_doc_hidden` on `TyCtxt`, but it wasn't used much, so I replaced the manual calls to `attrs(...).has_word(...)` with this method. Just by doing that, perf. was improved locally, although I'm not sure if the semantics of the previous calls and this method are the same?
As another step, I tried to querify `is_doc_hidden`, but I didn't include that here until we see the perf. results from the first commit and until I find whether this change is OK at all :)
bors [Fri, 24 Dec 2021 23:12:14 +0000 (23:12 +0000)]
Auto merge of #92229 - fee1-dead:fix-rustdoc-const-drop, r=dtolnay
Do not display `~const Drop` in rustdoc
Although `T: ~const Drop` is still at an experimental stage, we have already begun inserting these bounds in libstd. This change hides them from rustdoc because 1. `~const` should not be documented in general as it is not yet official syntax; 2. users are not expected to know what `~const Drop` means yet.
bors [Fri, 24 Dec 2021 10:02:54 +0000 (10:02 +0000)]
Auto merge of #92226 - woppopo:const_black_box, r=joshtriplett
Constify `core::intrinsics::black_box` and `core::hint::black_box`.
`core::intrinsics::black_box` is already constified, but it wasn't marked as const (see: https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/intrinsics.rs#L471).
bors [Fri, 24 Dec 2021 04:59:05 +0000 (04:59 +0000)]
Auto merge of #91342 - RalfJung:fn-abi, r=eddyb,oli-obk
CTFE eval_fn_call: use FnAbi to determine argument skipping and compatibility
This makes use of the `FnAbi` type in CTFE/Miri, which `@eddyb` has been saying for years is what we should do.^^ `FnAbi` is used to
- determine which arguments to skip (rather than the previous heuristic of skipping ZST arguments with the Rust ABI)
- impose further restrictions on whether caller and callee are consistent in how a given argument is passed
I was hoping it would also simplify the code, but that is not the case -- the previous type compatibility checks are still required (AFAIK), only the ZST skipping is gone and that took barely any code. We also need some hacks because `FnAbi` assumes a certain way of implementing `caller_location` (by passing extra arguments), but Miri can just read the caller location from the call stack so it doesn't need those arguments. (The fact that every backend has to separately implement support for these arguments seems suboptimal -- looks like this might have been better implemented on the MIR level.) To avoid having to implement those unnecessary arguments in Miri, we just compute *whether* the argument is present on the caller/callee side, but don't actually pass that argument around.
I have no idea if this looks the way `@eddyb` thinks it should look... but it makes Miri's test suite pass. ;)
One of rustc's tests fails unfortunately (`ui/const-generics/issues/issue-67739.rs`), some const generic code that is evaluated too early -- I think that should raise `TooGeneric` but instead it ICEs. My assumption is this is some FnAbi code that has not been properly tested on polymorphic code, but it might also be me calling that FnAbi code the wrong way.
r? `@oli-obk` `@eddyb`
Fixes https://github.com/rust-lang/rust/issues/56166
Miri PR at https://github.com/rust-lang/miri/pull/1928
bors [Fri, 24 Dec 2021 01:54:56 +0000 (01:54 +0000)]
Auto merge of #92220 - nnethercote:RawVec-dont-recompute-capacity, r=joshtriplett
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 [Thu, 23 Dec 2021 19:43:04 +0000 (19:43 +0000)]
Auto merge of #92232 - matthiaskrgr:rollup-eqdac7z, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #90625 (Add `UnwindSafe` to `Once`)
- #92121 (disable test with self-referential generator on Miri)
- #92166 (Fixed a small typo in ui test comments)
- #92203 (Store a `DefId` instead of an `AdtDef` in `AggregateKind::Adt`)
- #92231 (Update books)
3 commits in 954f3d441ad880737a13e241108f791a4d2a38cd..06f9e61931bcf58b91dfe6c924057e42ce273ee1
2021-11-29 11:11:30 -0800 to 2021-12-17 07:31:40 -0800
- keep consistent for primitive types (rust-lang/reference#1118)
- README.md: link to mdbook docs (rust-lang/reference#1117)
- Say that `...` range patterns are rejected in the 2021 edition (rust-lang/reference#1114)
## book
4 commits in 5f9358faeb1f46e19b8a23a21e79fd7fe150491e..8a0bb3c96e71927b80fa2286d7a5a5f2547c6aa4
2021-12-05 21:33:16 -0500 to 2021-12-22 20:54:27 -0500
- Propagate edits back
- Fix number disagreement. Fixes rust-lang/book#2858.
- Wrap some code in main to make scopes clearer. Fixes rust-lang/book#2830.
- Respond to ch5 nostarch edits
## rustc-dev-guide
9 commits in a374e7d8bb6b79de45b92295d06b4ac0ef35bc09..9bf0028b557798ddd07a6f652e4d0c635d3d6620
2021-12-03 09:26:47 -0800 to 2021-12-20 21:53:57 +0900
- remove rustfix item in test intro (rust-lang/rustc-dev-guide#1277)
- Move date-check comment to fix Markdown syntax
- Update humor docs for special-casing ferris emoji
- Fix some broken links (rust-lang/rustc-dev-guide#1274)
- Update rustdoc internals
- Update HIR chapter to use `HirId` instead of `NodeId`
- Fix some broken links
- Update src/getting-started.md
- Improve documentation on r?
Matthias Krüger [Thu, 23 Dec 2021 16:48:31 +0000 (17:48 +0100)]
Rollup merge of #92203 - Aaron1011:mir-adt-def, r=oli-obk
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.
Matthias Krüger [Thu, 23 Dec 2021 16:48:30 +0000 (17:48 +0100)]
Rollup merge of #92121 - RalfJung:miri-core-test, r=kennytm
disable test with self-referential generator on Miri
Running the libcore test suite in Miri currently fails due to the known incompatibility of self-referential generators with Miri's aliasing checks (https://github.com/rust-lang/unsafe-code-guidelines/issues/148). So let's disable that test in Miri for now.
bors [Thu, 23 Dec 2021 16:12:23 +0000 (16:12 +0000)]
Auto merge of #92110 - nagisa:def-inlining, r=nikic
Backport LLVM changes to disable deferred inlining
Fixes #91128
I was thinking of how to best add the test case from the issue, and I think rust perf infrastructure would probably be the best place for something like it.
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.
projects / rust.git / log