Remove potential useless data for search index
I uncovered this case when working on https://github.com/rust-lang/rust/pull/90726 to debug https://github.com/rust-lang/rust/pull/90385.
Explanations: if we have a full generic, we check if it has generics then we do the following:
* If it has only one generic, we remove one nested level in order to not keep the "parent" generic (since it has empty name, it's useless after all).
* Otherwise we add it alongside its generics.
However, I didn't handle the case where a generic had no generics. Meaning that we were adding items with empty names in the search index. So basically useless data in the search index.
r? `@camelid`
Use computed visibility in rustdoc
This PR changes `librustdoc` to use computed visibility instead of syntactic visibility. It was initially part of #88019, but was separated due to concerns that it might cause a regression somewhere we couldn't predict.
r? `@jyn514`
cc `@cjgillot` `@petrochenkov`
Update llvm submodule
This includes debug info generation fix, that fixes#90301.
Also includes WASM backend related fix for https://bugs.llvm.org/show_bug.cgi?id=52352
(I haven't found a corresponding Rust bug).
Because after PR 86041, the optimizer no longer load-merges at the LLVM IR level, which might be part of the perf loss. (I'll run perf and see if this makes a difference.)
Also I added a codegen test so this hopefully won't regress in future -- it passes on stable and with my change here, but not on the 2021-11-09 nightly.
Update books
## nomicon
1 commits in 358e6a61d5f4f0496d0a81e70cdcd25d05307342..c6b4bf831e9a40aec34f53067d20634839a6778b
2021-10-20 11:23:12 -0700 to 2021-11-09 02:30:56 +0900
- Replace some use of variant with covariant (rust-lang/nomicon#322)
## book
11 commits in fd9299792852c9a368cb236748781852f75cdac6..5c5dbc5b196c9564422b3193264f3288d2a051ce
2021-10-22 21:59:46 -0400 to 2021-11-09 19:30:43 -0500
- Fix constants link.
- Fix updated anchor
- Propagate edits to chapter 2 back
- Edits to nostarch's chapter 3 edits
- ch 3 from nostarch
- Fix Cargo.toml snippet about custom derive macros
- Snapshot of chapter 9 for nostarch
- Create tmp/src for converting quotes, not sure why this broke but ok
- Update question mark to better explain where it can be used
- Clarify sentence about Results in functions that don't return Result. Fixesrust-lang/book#2912.
- Merge pull request rust-lang/book#2913 from covariant/patch-1
## rust-by-example
2 commits in 27f1ff5e440ef78828b68ab882b98e1b10d9af32..e9d45342d7a6c1def4731f1782d87ea317ba30c3
2021-10-13 08:04:40 -0300 to 2021-11-02 13:33:03 -0500
- Enums: Linked-List Needs Re-Wording (rust-lang/rust-by-example#1469)
- fix: Use the point as top left corner for `square` (rust-lang/rust-by-example#1471)
## rustc-dev-guide
13 commits in b06008731af0f7d07cd0614e820c8276dfed1c18..196ef69aa68f2cef44f37566ee7db37daf00301b
2021-10-21 15:13:09 -0500 to 2021-11-07 07:48:47 -0600
- Fix typo: [upv.rs_mentioned] -> [upvars_mentioned]
- Add note to emphasize replacing TARGET_TRIPLE (rust-lang/rustc-dev-guide#1250)
- Remove some legacy test suites.
- tiny capitalization fix
- Fix date
- Update some date-check comments
- Ensure date-check cron job is using latest stable Rust
- enhance subtree docs, link to clippy docs
- Edit introduction to bootstrapping
- Some minor adjustments to the diagnostic documentation
- Edit "About this guide" for semantic line feeds
- Fix `rustc_mir` related links (rust-lang/rustc-dev-guide#1228)
- Add documentation for LLVM CFI support
## edition-guide
3 commits in 7c0088ca744d293a5f4b1e2ac378e7c23d30fe55..27f4a84d3852e9416cae5861254fa53a825c56bd
2021-10-05 13:28:05 +0200 to 2021-11-08 10:13:20 -0500
- Add a missing period (rust-lang/edition-guide#271)
- Fix syntax error in code example (rust-lang/edition-guide#270)
- Fixed an example error of prelude.md (rust-lang/edition-guide#269)
Support early stopping too old pre-installed `tidy` command for macOS in the HTML checker
This PR brings early stopping the HTML checker before errors, which leave some macOS users confused, and suggesting installing a newer `tidy` command.
The pre-installed `tidy` command on macOS is too old, released on 31 October 2006. Additionally, I can see the same date at [StackOverflow](https://stackoverflow.com/questions/22283382/overwrite-osx-tidy
) seven years ago. The `tidy` does not support two indispensable options: `--mute-id` and `--mute`. So, the `./x.py test` command fails with a bunch of errors due not to muting them.
I could confirm the `./x.py test` command before installing a newer `tidy` failed and its command after the installation succeeded.
Change the Miri engine to allow configuring whether to check
initialization of integers and floats. This allows the Miri tool to
optionally check for initialization if requested by the user.
Rollup of 7 pull requests
Successful merges:
- #89561 (Type inference for inline consts)
- #90035 (implement rfc-2528 type_changing-struct-update)
- #90613 (Allow to run a specific rustdoc-js* test)
- #90683 (Make `compiler-docs` only control the default instead of being a hard off-switch)
- #90685 (x.py: remove fixme by deleting code)
- #90701 (Record more artifact sizes during self-profiling.)
- #90723 (Better document `Box` and `alloc::alloc::box_free` connection)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Hashing does not have to use the whole Components parsing machinery because we only need it to match the
normalizations that Components does.
* stripping redundant separators -> skipping separators
* stripping redundant '.' directories -> skipping '.' following after a separator
That's all it takes.
And instead of hashing individual slices for each component we feed the bytes directly into the hasher which avoids
hashing the length of each component in addition to its contents.
Better document `Box` and `alloc::alloc::box_free` connection
The internal `alloc::alloc::box_free` function requires that its signature matches the `owned_box` struct's declaration, but previously that connection was only documented on the `box_free` function.
This PR makes the documentation two-way to help anyone making theoretical changes to `Box` to see the connection, since changes are more likely to originate from `Box`.
Record more artifact sizes during self-profiling.
This PR adds artifact size recording for
- "linked artifacts" (executables, RLIBs, dylibs, static libs)
- object files
- dwo files
- assembly files
- crate metadata
- LLVM bitcode files
- LLVM IR files
- codegen unit size estimates
Currently the identifiers emitted for these are hard-coded as string literals. Is it worth adding constants to https://github.com/rust-lang/measureme/blob/master/measureme/src/rustc.rs instead? We don't do that for query names and the like -- but artifact kinds might be more stable than query names.
implement rfc-2528 type_changing-struct-update
This PR implement rfc2528-type_changing-struct-update.
The main change process is as follows:
1. Move the processing part of `base_expr` into `check_expr_struct_fields` to avoid returning `remaining_fields` (a relatively complex hash table)
2. Before performing the type consistency check(`check_expr_has_type_or_error`), if the `type_changing_struct_update` feature is set, enter a different processing flow, otherwise keep the original flow
3. In the case of the same structure definition, check each field in `remaining_fields`. If the field in `base_expr` is not the suptype of the field in `adt_ty`, an error(`FeildMisMatch`) will be reported.
The MIR part does not need to be changed, because only the items contained in `remaining_fields` will be extracted from `base_expr` when MIR is generated. This means that fields with different types in `base_expr` will not be used
Updates #86618
cc `@nikomatsakis`
Type inference for inline consts
Fixes#78132Fixes#78174Fixes#81857Fixes#89964
Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.
Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts.
The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.
With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.
Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck).
cc `````@spastorino````` `````@lcnr`````
r? `````@nikomatsakis`````
`````@rustbot````` label A-inference F-inline_const T-compiler
