The memory fences used previously in Arc implementation are not properly
understood by ThreadSanitizer as synchronization primitives. This had
unfortunate effect where running any non-trivial program compiled with
`-Z sanitizer=thread` would result in numerous false positives.
Replace acquire fences with acquire loads when using ThreadSanitizer to
address the issue.
The manual implementation of PartialEq, Eq and Hash for RangeInclusive was functionally equivalent to a derived implementation.
This change removes the manual implementation and adds the respective derives.
A side effect of this change is that the derives also add implementations for StructuralPartialEq and StructuralEq, which enables RangeInclusive to be used in const generics.
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
As discussed on reddit, this commit addresses two issues with the
documentation of `mem::forget()`:
* The documentation of `mem::forget()` can confuse the reader because of the
discrepancy between usage examples that show correct usage and the
accompanying text which speaks of the possibility of double-free. The
text that says "if the panic occurs before `mem::forget` was called"
refers to a variant of the second example that was never shown, modified
to use `mem::forget` instead of `ManuallyDrop`. Ideally the documentation
should show both variants, so it's clear what it's talking about.
Also, the double free could be fixed just by placing `mem::forget(v)`
before the construction of `s`. Since the lifetimes of `s` and `v`
wouldn't overlap, there would be no point where panic could cause a double
free. This could be mentioned, and contrasted against the more robust fix
of using `ManuallyDrop`.
* This sentence seems unjustified: "For some types, operations such as
passing ownership (to a funcion like `mem::forget`) requires them to
actually be fully owned right now [...]". Unlike C++, Rust has no move
constructors, its moves are (possibly elided) bitwise copies. Even if you
pass an invalid object to `mem::forget`, no harm should come to pass
because `mem::forget` consumes the object and exists solely to prevent
drop, so there no one left to observe the invalid state state.
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
