This adds `nounused` to the set of extern flags:
`--extern nounused:core=/path/to/core/libcore.rlib`.
The effect of this flag is to suppress `unused-crate-dependencies`
warnings relating to the crate.
Remove visibility information from HIR
The resolver exports all the necessary visibility information through the `tcx.visibility` query.
This PR stops having a dedicated visibility field in HIR, in order to use this query.
We keep a `vis_span` field for diagnostic purposes.
Unstably constify `impl<I: Iterator> IntoIterator for I`
This constifies the default `IntoIterator` implementation under the `const_intoiterator_identity` feature.
Tracking Issue: #90603
No "weird" floats in const fn {from,to}_bits
I suspect this code is subtly incorrect and that we don't even e.g. use x87-style floats in CTFE, so I don't have to guard against that case. A future PR will be hopefully removing them from concern entirely, anyways. But at the moment I wanted to get this rolling because small questions like that one seem best answered by review.
r? `@oli-obk`
cc `@eddyb` `@thomcc`
debuginfo: Emit ZST struct debuginfo for unit type when CPP-like debuginfo is enabled
As already discovered in 24a728a8eb, PDB does not play well with custom basic types. This PR extends to the fix to `()`: Instead of a custom basic type, we treat it like an empty tuple (i.e. it is described as a struct which happens to have no fields).
Before this change anything with a `()` in it would cause trouble, which is especially bad for `*const ()` and `*mut ()` which are often used for opaque pointers. E.g. the test case added in this PR would look like:
```
0:000> dx _ref
Error: Unable to bind name '_ref'
0:000> dx _ptr
Error: Unable to bind name '_ptr'
0:000> dx _local
Error: Unable to bind name '_local'
0:000> dx _field,d
_field,d [Type: unit_type::_TypeContainingUnitField]
[+0x008] _a : 123 [Type: unsigned int]
[+0x000] _unit : Unexpected failure to dereference object
[+0x000] _b : 456 [Type: unsigned __int64]
0:000> dx ((__int64 *)_ptr),x
Error: Unable to bind name '_ptr'
```
With the PR it produces the expected output:
```
0:000> dx _ref
_ref : 0x7ff6f2012230 : () [Type: tuple$<> *]
0:000> dx _ptr
_ptr : 0x7e8ddffc20 : () [Type: tuple$<> *]
0:000> dx _local
_local : () [Type: tuple$<>]
0:000> dx _field,d
_field,d [Type: unit_type::_TypeContainingUnitField]
[+0x008] _a : 123 [Type: unsigned int]
[+0x000] _unit : () [Type: tuple$<>]
[+0x000] _b : 456 [Type: unsigned __int64]
0:000> dx ((__int64 *)_ptr),x
((__int64 *)_ptr),x : 0x7e8ddffc20 : 0x1122334455667788 [Type: __int64 *]
```
r? `@wesleywiser`
Rollup of 3 pull requests
Successful merges:
- #96272 (Update `validate_uninhabited_zsts.rs` test after MIR building changes)
- #96273 (Make `E0117` error clear)
- #96315 (Make the lifetime accurate which is used in the region constraints part)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update `validate_uninhabited_zsts.rs` test after MIR building changes
to ensure that it still tests validation, instead of failing earlier on
during evaluation.
r? `@RalfJung`
Ensure existance of dist directory when creating tarball
I'm not sure why this works in CI, but this is necessary to make distcheck (including the `x86_64-linux-distcheck` image) run on Fedora 35.
rustdoc: Unindent doc fragments on `Attributes` construction
`Attributes` can be constructed at arbitrary points, even after the `unindent_comments` pass.
`Attributes` that are constructed too late end up unindented.
All doc fragments need to be eventually indented before use, so there are no reasons to not do this immediately during their construction.
Fixes https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.60unindent_comments.60.20cannot.20work.20as.20a.20separate.20pass.
I'm not sure how to make a minimized reproduction, but unindenting the fragments during their construction should fix the issue.. by construction, and I also verified that all doc strings now hit the `resolver_caches.markdown_links` cache in https://github.com/rust-lang/rust/pull/94857.
bootstrap: consolidate subcommand parsing and matching
There's several places where the x.py command names are matched as
strings, leading to some inconsistencies and opportunities for cleanup.
* Add Format, Clean, and Setup variants to builder::Kind.
* Use Kind to parse the x.py subcommand name (including aliases)
* Match on the subcommand Kind rather than strings when handling
options and help text.
* Several subcommands don't display any paths when run with `-h -v` even
though the help text indicates that they should. Fix this and refactor
so that manually keeping matches in sync isn't necessary.
Fixes#95937
bootstrap: add split-debuginfo config
Replace `run-dysutil` option with more general `split-debuginfo` option that works on all platforms.
r? `@Mark-Simulacrum`
Rollup of 5 pull requests
Successful merges:
- #90630 (Create real parser for search queries)
- #96193 ([fuchsia] Add implementation for `current_exe`)
- #96196 (Remove assertion that all paths in `ShouldRun` exist)
- #96228 (Fix locations for intrinsics impls and change to links)
- #96236 (Add an explicit `Span` field to `OutlivesConstraint`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add an explicit `Span` field to `OutlivesConstraint`
Previously, we would retrieve the span from the `Body` using
the `locations` field. However, we may end up changing the
`locations` field when moving a constraint from a promoted
to a different body.
We now store the original `Span` in a dedication field, so that
changes to the `locations` do not affect the quality of our
diagnostics.
Remove assertion that all paths in `ShouldRun` exist
This breaks on submodules (see #96188). Disable the assertion for now until I can think of a proper
fix.
This doesn't revert any of the changes in `Step`s themselves, only what
`ShouldRun::paths` does.
Create real parser for search queries
You can test it [here](https://rustdoc.crud.net/imperio/improve-rustdoc-search/std/index.html).
This PR adds a real parser for the query engine in rustdoc. The parser is quite simple but it allows to makes query handling much easier. I added a new testsuite to ensure it works as expected and ran fuzzing checks on it for a few hours without problems.
So about the parser: as you can see in the screenshot, it handles recursive generics parsing. It also allows to set which item should use exact matching by adding double-quotes around it (look for `exact_search` in the screenshot).
Now about the query engine itself: I simplified it a lot thanks to the parsed query. It behaves mostly the same when there is only one argument, but is much more powerful when there are more than one.
When making this change, we also removed the support for multi-query.
PS: A big part of the PR is tests and test-related code. :)
r? `@camelid`
Check if call return type is visibly uninhabited when building MIR
The main motivation behind the change is to expose information about diverging
calls to the generator transform and match the precision of drop range tracking
which already understands that call expressions with visibly uninhabited types
diverges.
This change should also accept strictly more programs than before. That is
programs that were previously rejected due to errors raised by control-flow
sensitive checks in a code that is no longer considered reachable.
Fixes#93161.
