There were a few places in rustdoc where we would take static JS or CSS and rewrite it at doc generation time to insert values. This consolidates all the CSS instances into one CSS file and replaces the JS examples with data- attributes on the rustdoc-vars div.
Matthias Krüger [Sat, 27 Nov 2021 10:46:42 +0000 (11:46 +0100)]
Rollup merge of #91057 - the8472:clarify-parallelism-steady-state, r=dtolnay
Expand `available_parallelism` docs in anticipation of cgroup quota support
The "fixed" in "fixed steady state limits" means to exclude load-dependent resource prioritization
that would calculate to 100% of capacity on an idle system and less capacity on a loaded system.
Additionally I also exclude "system load" since it would be silly to try to identify
other, perhaps higher priority, processes hogging some CPU cores that aren't explicitly excluded
by masks/quotas/whatever.
Matthias Krüger [Sat, 27 Nov 2021 10:46:42 +0000 (11:46 +0100)]
Rollup merge of #90995 - the8472:hash-portability, r=dtolnay
Document non-guarantees for Hash
Dependence on endianness and type sizes was reported for enum discriminants in #74215 but it is a more general
issue since for example the default implementation of `Hasher::write_usize` uses native endianness.
Additionally the implementations of library types are occasionally changed as their internal fields
change or hashing gets optimized.
## Question
Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`?
Matthias Krüger [Sat, 27 Nov 2021 10:46:40 +0000 (11:46 +0100)]
Rollup merge of #83791 - the8472:relax-zip-side-effect-guarantee, r=dtolnay
Weaken guarantee around advancing underlying iterators in zip
The current guarantee (introduced in #52279) is too strong as it prevents adapters from exploiting knowledge about the iterator length and using counted loops for example because they would stop calling `next()` before it ever returned `None`. Additionally several nested zip iterators already fail to uphold this.
This does not yet remove any of the specialization code that tries (and sometimes fails) to uphold the guarantee for `next()`
because removing it would also affect `next_back()` in more surprising ways.
The intent is to be able to remove for example this branch
Matthias Krüger [Fri, 26 Nov 2021 21:41:44 +0000 (22:41 +0100)]
Rollup merge of #91259 - jyn514:doctest-warnings, r=GuillaumeGomez
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
Matthias Krüger [Fri, 26 Nov 2021 21:41:41 +0000 (22:41 +0100)]
Rollup merge of #91240 - dtolnay:utf8width, 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.
If the first element of a top docblock is a heading, we still need to keep the indent, but only on this one (I added a test to check it). We need it because otherwise the anchor will go over the `[-]` toggle.
Matthias Krüger [Fri, 26 Nov 2021 21:41:39 +0000 (22:41 +0100)]
Rollup merge of #91197 - camelid:rename-resolvedpath, r=GuillaumeGomez,jyn514
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.
bors [Fri, 26 Nov 2021 21:35:53 +0000 (21:35 +0000)]
Auto merge of #91246 - nnethercote:faster-layout-array, r=dtolnay
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.
bors [Fri, 26 Nov 2021 16:30:42 +0000 (16:30 +0000)]
Auto merge of #91253 - matthiaskrgr:rollup-dnlcjmr, r=matthiaskrgr
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)
Matthias Krüger [Fri, 26 Nov 2021 15:02:23 +0000 (16:02 +0100)]
Rollup merge of #91169 - RDambrosio016:master, r=bjorn3
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.
bors [Fri, 26 Nov 2021 13:42:35 +0000 (13:42 +0000)]
Auto merge of #91164 - Badel2:usefulness-stack-overflow, r=davidtwco
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.
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::new::<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.)
bors [Fri, 26 Nov 2021 06:44:00 +0000 (06:44 +0000)]
Auto merge of #91181 - GuillaumeGomez:improve-rustdoc-gui-ci, r=jsha
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.
bors [Fri, 26 Nov 2021 03:57:55 +0000 (03:57 +0000)]
Auto merge of #85102 - estebank:point-at-assignment, r=oli-obk
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
Noah Lev [Wed, 24 Nov 2021 20:27:37 +0000 (12:27 -0800)]
Stop re-exporting `Type::ResolvedPath`
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.
Esteban Küber [Fri, 7 May 2021 02:09:35 +0000 (19:09 -0700)]
On type mismatch caused by assignment, point at assignee
* 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
Matthias Krüger [Thu, 25 Nov 2021 14:05:40 +0000 (15:05 +0100)]
Rollup merge of #91185 - camelid:rm-force-overflow-checks, r=wesleywiser
Remove `-Z force-overflow-checks`
It was replaced several years ago by the stable option `-C overflow-checks`.
The goal was to delete the `-Z` flag once users had migrated [1].
Now that it's been several years, it makes sense to delete the old flag.
Matthias Krüger [Thu, 25 Nov 2021 14:05:38 +0000 (15:05 +0100)]
Rollup merge of #91111 - cjgillot:hir-no-lower-attrs, r=michaelwoerister
Do not visit attributes in `ItemLowerer`.
By default, AST visitors visit expressions that appear in key-value attributes.
Those expressions should not be lowered to HIR, as they do not correspond to actually compiled code.
Since an attribute cannot produce meaningful HIR, just skip them altogether.
Matthias Krüger [Thu, 25 Nov 2021 14:05:37 +0000 (15:05 +0100)]
Rollup merge of #91096 - compiler-errors:elaborate_opaque_trait, r=estebank
Print associated types on opaque `impl Trait` types
This PR generalizes #91021, printing associated types for all opaque `impl Trait` types instead of just special-casing for future.
before:
```
error[E0271]: type mismatch resolving `<impl Iterator as Iterator>::Item == u32`
```
after:
```
error[E0271]: type mismatch resolving `<impl Iterator<Item = usize> as Iterator>::Item == u32`
```
---
Questions:
1. I'm kinda lost in binders hell with this one. Is all of the `rebind`ing necessary?
2. Is there a map collection type that will give me a stable iteration order? Doesn't seem like TraitRef is Ord, so I can't just sort later..
3. I removed the logic that suppresses printing generator projection types. It creates outputs like this [gist](https://gist.github.com/compiler-errors/d6f12fb30079feb1ad1d5f1ab39a3a8d). Should I put that back?
4. I also added spaces between traits, `impl A+B` -> `impl A + B`. I quite like this change, but is there a good reason to keep it like that?
Matthias Krüger [Thu, 25 Nov 2021 14:05:36 +0000 (15:05 +0100)]
Rollup merge of #90499 - rusticstuff:macos-target-fixes, r=petrochenkov
Link with default MACOSX_DEPLOYMENT_TARGET if not otherwise specified.
This PR sets the MACOSX_DEPLOYMENT_TARGET environment variable during the linking stage to our default, if it is not specified. This way it matches the deployment target we pass to llvm. If not set the the linker uses Xcode or Xcode commandline tools default which varies by version.
Fixes #90342, #91082.
Drive-by fixes to make Rust behave more like clang:
* Default to 11.0 deployment target for ARM64 which is the earliest version that had support for it.
* Set the llvm target to `arm64-apple-macosx<deployment target>` instead of `aarch64-apple-macosx<deployment target>`.
Matthias Krüger [Thu, 25 Nov 2021 14:05:35 +0000 (15:05 +0100)]
Rollup merge of #89359 - fee1-dead:const-it, r=oli-obk
Various fixes for const_trait_impl
A few problems I found while making `Iterator` easier to const-implement.
1. More generous `~const Drop` check.
We check for nested fields with caller bounds.
For example, an ADT type with fields of types `A`, `B`, `C`, check if all of them are either:
- Bounded (`A: ~const Drop`, `B: Copy`)
- Known to be able to destruct at compile time (`C = i32`, `struct C(i32)`, `C = some_fn`)
2. Don't treat trait functions marked with `#[default_method_body_is_const]` as stable const fns when checking `const_for` and `const_try` feature gates.
I think anyone can review this, so no r? this time.
bors [Thu, 25 Nov 2021 13:11:35 +0000 (13:11 +0000)]
Auto merge of #91195 - camelid:path-did, r=jyn514
rustdoc: Remove `ResolvedPath.did`
`ResolvedPath.did` was not actually the same as `.path.def_id()`. Instead,
`.did` referred to the `DefId` of the page to be used as a hyperlink target.
For example, a link to `Struct::method()` would use `Struct`'s `DefId` as its
`.did` field. This behavior is confusing, easy to accidentally misuse, and can
instead be obtained on-demand when computing hyperlink targets. It's also likely
part of the reason `kind_side_channel` exists. I'm currently working on some
experimental refactorings in `collect_intra_doc_links` that I believe require --
or at least benefit from -- removing `.did`.
We had been injecting the list of themes and the rustdoc version into
main.js by rewriting it at doc generation time. By avoiding this
rewrite, we can make it easier to edit main.js without regenerating all
the docs.
Added a more convenient accessor for rustdoc-vars.
Changed storage.js to not rely on resourcesSuffix. It could in theory
use rustdoc-vars, but because rustdoc-vars is at the end of the HTML,
it's not available when storage.js runs (very early in page load).
We carry around a list of stylesheets that can carry two different types
of thing:
1. Internal stylesheets specific to a page type (only for settings)
2. Themes
In this change I move the link generation for settings.css into
settings(), so Context.style_files is reserved just for themes.
We had two places where we extracted a base theme name from a list of
StylePaths. I consolidated that code to be a method on StylePath.
I moved generation of link tags for stylesheets into the page.html
template. With that change, I made the template responsible for special
handling of light.css (making it the default theme) and of the other
themes (marking them disabled). That allowed getting rid of the
`disabled` field on StylePath.
bors [Wed, 24 Nov 2021 23:09:42 +0000 (23:09 +0000)]
Auto merge of #91203 - GuillaumeGomez:rollup-kwtqvb1, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #89542 (Partially stabilize `duration_consts_2`)
- #90044 (Restrict aarch64 outline atomics to glibc for now.)
- #90420 (Create rustdoc_internals feature gate)
- #91075 (Reduce prominence of item-infos)
- #91151 (Fix test in std::process on android)
- #91179 (Fix more <a> color)
- #91199 (rustdoc: Add test for mixing doc comments and attrs)
Guillaume Gomez [Wed, 24 Nov 2021 21:56:37 +0000 (22:56 +0100)]
Rollup merge of #91075 - jsha:chill-item-info, r=GuillaumeGomez
Reduce prominence of item-infos
Fixes #59853
- Remove border.
- Reduce size of emoji slightly.
- Remove details disclosure for unstable reason. This was inconsistent with our other details disclosures, and the detail revealed was usually better explained by clicking on the issue link.
Guillaume Gomez [Wed, 24 Nov 2021 21:56:37 +0000 (22:56 +0100)]
Rollup merge of #90420 - GuillaumeGomez:rustdoc-internals-feature, r=camelid
Create rustdoc_internals feature gate
As suggested by ``@camelid`` [here](https://github.com/rust-lang/rust/pull/90398#issuecomment-955093851), since `doc_keyword` and `doc_primitive` aren't meant to be stabilized, we could put them behind a same feature flag.
This is pretty much what it would look like (needs to update the tests too).
The tracking issue is https://github.com/rust-lang/rust/issues/90418.
Guillaume Gomez [Wed, 24 Nov 2021 21:56:36 +0000 (22:56 +0100)]
Rollup merge of #90044 - rusticstuff:disable_arm_outline_atomics_for_musl, r=workingjubilee
Restrict aarch64 outline atomics to glibc for now.
The introduced dependency on `getauxval` causes linking problems with musl, making compiling any binaries for `aarch64-unknown-linux-musl` impossible without workarounds such as using lld or adding liblibc.rlib again to the linker invocation, see #89626.
This is a workaround until libc>0.2.108 is merged.
Guillaume Gomez [Wed, 24 Nov 2021 21:56:35 +0000 (22:56 +0100)]
Rollup merge of #89542 - jhpratt:stabilize-duration-const-fns, r=oli-obk
Partially stabilize `duration_consts_2`
Methods that were only blocked on `const_panic` have been stabilized.
The remaining methods of `duration_consts_2` are all related to floats,
and as such have been placed behind the `duration_consts_float` feature
gate.
Noah Lev [Thu, 11 Nov 2021 23:05:25 +0000 (15:05 -0800)]
Return the actual `DefId` for assoc. items in `register_res`
Before, if `register_res` were called on an associated item or enum
variant, it would return the parent's `DefId`. Now, it returns the
actual `DefId`.
This change is a step toward removing `Type::ResolvedPath.did` and
potentially removing `kind_side_channel` in rustdoc. It also just
simplifies rustdoc's behavior.
Noah Lev [Wed, 24 Nov 2021 18:19:23 +0000 (10:19 -0800)]
Remove `-Z force-overflow-checks`
It was replaced several years ago by the stable option `-C
overflow-checks`. The goal was to delete the `-Z` flag once users had
migrated [1]. Now that it's been several years, it makes sense to delete
the old flag.
bors [Wed, 24 Nov 2021 15:51:46 +0000 (15:51 +0000)]
Auto merge of #90491 - Mark-Simulacrum:push-pred-faster, r=matthewjasper
Optimize live point computation
This refactors the live-point computation to lower per-MIR-instruction costs by operating on a largely per-block level. This doesn't fundamentally change the number of operations necessary, but it greatly improves the practical performance by aggregating bit manipulation into ranges rather than single-bit; this scales much better with larger blocks.
On the benchmark provided in #90445, with 100,000 array elements, walltime for a check build is improved from 143 seconds to 15.
I consider the tiny losses here acceptable given the many small wins on real world benchmarks and large wins on stress tests. The new code scales much better, but on some subset of inputs the slightly higher constant overheads decrease performance somewhat. Overall though, this is expected to be a big win for pathological cases (as illustrated by the test case motivating this work) and largely not material for non-pathological cases. I consider the new code somewhat easier to follow, too.