Extend search
I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check.
To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future.
About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search.
I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1".
r? @kinnison
cc @ollie27
rustc: use LocalDefId instead of DefIndex where possible.
That is, wherever `DefIndex` always referred to a "def" in the local crate, I replaced it with `LocalDefId`.
While `LocalDefId` already existed, it wasn't used a lot, but I hope I'm on the right track.
Unresolved questions:
* [x] ~~should `LocalDefId` implement `rustc_index::Idx`?~~
* ~~this would get rid of a couple more `DefIndex` uses~~
* [x] ~~should `LocalDefId` be encoded/decoded as just a `DefIndex`?~~
* ~~right now it's a bit messy, `LocalDefId` encodes/decodes like `DefId`~~
* [x] ~~should `DefId::assert_local` be named something else, like `expect_local`?~~
A future PR should change `tcx.hir().local_def_id(...)` to return `LocalDefId` instead of `DefId`, as changing it in this PR would be too noisy.
r? @michaelwoerister cc @nikomatsakis @petrochenkov @Zoxc
Rollup of 9 pull requests
Successful merges:
- #68941 (Properly handle Spans that reference imported SourceFiles)
- #69036 (rustc: don't resolve Instances which would produce malformed shims.)
- #69443 (tidy: Better license checks.)
- #69814 (Smaller and more correct generator codegen)
- #69929 (Regenerate tables for Unicode 13.0.0)
- #69959 (std: Don't abort process when printing panics in tests)
- #69969 (unix: Set a guard page at the end of signal stacks)
- #70005 ([rustdoc] Improve visibility for code blocks warnings)
- #70088 (Use copy bound in atomic operations to generate simpler MIR)
Failed merges:
r? @ghost
unix: Set a guard page at the end of signal stacks
This mitigates possible issues when signal stacks overflow, which could
manifest as segfaults or in unlucky circumstances possible clobbering of
other memory values as stack overflows tend to enable.
I went ahead and made a PR for this because it's a pretty small change, though if I should open an issue/RFC for this and discuss there first I'll happily do so. I've also added some example programs that demonstrate the uncomfortably clobber-happy behavior we currently have, and the segfaults that could/should result instead, [here](https://github.com/iximeow/jubilant-train).
std: Don't abort process when printing panics in tests
This commit fixes an issue when using `set_print` and friends, notably
used by libtest, to avoid aborting the process if printing panics. This
previously panicked due to borrowing a mutable `RefCell` twice, and this
is worked around by borrowing these cells for less time, instead
taking out and removing contents temporarily.
Closes#69558
Smaller and more correct generator codegen
This removes unnecessary panicking branches in the resume function when the generator can not return or unwind, respectively.
Closes https://github.com/rust-lang/rust/issues/66100
It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though.
r? @Zoxc
tidy: Better license checks.
This implements some improvements to the license checks in tidy:
* Use `cargo_metadata` instead of parsing vendored crates. This allows license checks to run without vendoring enabled, and allows the checks to run on PR builds.
* Check for stale entries.
* Check that the licenses for exceptions are what we think they are.
* Verify exceptions do not leak into the runtime.
Closes#62618Closes#62619Closes#63238 (I think)
There are some substantive changes here. The follow licenses have changed from the original comments:
* openssl BSD+advertising clause to Apache-2.0
* pest MPL2 to MIT/Apache-2.0
* smallvec MPL2 to MIT/Apache-2.0
* clippy lints MPL2 to MIT OR Apache-2.0
rustc: don't resolve Instances which would produce malformed shims.
There are some `InstanceDef` variants (shims and drop "glue") which contain a `Ty`, and that `Ty` is used in generating the shim MIR. But if that `Ty` mentions any generic parameters, the generated shim would refer to them (but they won't match the `Substs` of the `Instance`), or worse, generating the shim would fail because not enough of the type is known.
Ideally we would always produce a "skeleton" of the type, e.g. `(_, _)` for dropping any tuples with two elements, or `Vec<_>` for dropping any `Vec` value, but that's a lot of work, and they would still not match the `Substs` of the `Instance` as it exists today, so `Instance` would probably need to change.
By making `Instance::resolve` return `None` in the still-generic cases, we get behavior similar to specialization, where a default can only be used if there are no more generic parameters which would allow a more specialized `impl` to match.
<hr/>
This was found while testing the MIR inliner with #68965, because it was trying to inline shims.
cc @rust-lang/wg-mir-opt
Properly handle Spans that reference imported SourceFiles
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. This currently has no visible consequences, since these
kinds of spans don't currently seem to be emitted anywhere. However,
there's no reason that we couldn't start using such spans in
diagnostics.
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
To support this change, I've also made the following modifications:
* `DefId` and related structs are now moved to `rustc_span`. This allows
us to use a `CrateNum` inside `SourceFile`. `CrateNum` has special
handling during deserialization (it gets remapped to be the proper
`CrateNum` from the point of view of the current compilation session),
so using a `CrateNum` instead of a plain integer 'workaround type' helps
to simplify deserialization.
* The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. These leads to sub-optimal error messages in certain cases
(see the included test).
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
ci: use python from the correct path
Apparently the old path we were using for Python 2 on Windows was not documented, and eventually got removed. This switches our CI to use the correct path.
See https://github.com/rust-lang/rust/pull/70112#issuecomment-600760786 for the actual failure.
Apparently the old path we were using for Python 2 on Windows was not
documented, and eventually got removed. This switches our CI to use the
correct path.
Tidy: fix running rustfmt twice
`./x.py test tidy` runs rustfmt twice. This is because `Build::build` runs `execute_cli` twice (once dry, once not). This can be quite slow (and prints a bunch of things twice).
I'm not sure if this is really the best place to check the dry_run status.
Remove some imports to the rustc crate
- When we have `NestedVisitorMap::None`, we use `type Map = dyn intravisit::Map<'v>;` instead of the actual map. This doesn't actually result in dynamic dispatch (in the future we may want to use an associated type default to simplify the code).
- Use `rustc_session::` imports instead of `rustc::{session, lint}`.
r? @Zoxc
Make methods declared by `newtype_index` macro `const`
Crates that use the macro to define an `Idx` type need to enable `#![feature(const_if_match, const_panic)]`.
Expansion-driven outline module parsing
After this PR, the parser will not do any conditional compilation or loading of external module files when `mod foo;` is encountered. Instead, the parser only leaves `mod foo;` in place in the AST, with no items filled in. Expansion later kicks in and will load the actual files and do the parsing. This entails that the following is now valid:
```rust
#[cfg(FALSE)]
mod foo {
mod bar {
mod baz; // `foo/bar/baz.rs` doesn't exist, but no error!
}
}
```
Fixes https://github.com/rust-lang/rust/issues/64197.
r? @petrochenkov
Use smaller discriminants for generators
Closes https://github.com/rust-lang/rust/issues/69815
I'm not yet sure about the runtime performance impact of this, so I'll try running this on some benchmarks (if I can find any). (Update: No impact on the benchmarks I've measured on)
* [x] Add test with a generator that has exactly 256 total states
* [x] Add test with a generator that has more than 256 states so that it needs to use a u16 discriminant
* [x] Add tests for the size of `Option<[generator]>`
* [x] Add tests for the `discriminant_value` intrinsic in all cases
Erase regions in writeback
Regions in `TypeckTables` (except canonicalized user annotations) are now erased. Further, we no longer do lexical region solving on item bodies with `-Zborrowck=mir`.
cc #68261
r? @nikomatsakis
