Expand the documentation for the `std::sync` module
I've tried to expand the documentation for Rust's synchronization primitives. The module level documentation explains why synchronization is required when working with a multiprocessor system,
and then links to the appropiate structure in this module.
Fixes#29377, since this should be the last item on the checklist (documentation for `Atomic*` was fixed in #44854, but not ticked off the checklist).
Cleanup rustc/ty part 2
The second part of cleanups and minor improvements for rustc/ty.
- improve allocations
- calculate span after a possible early continue
- simplify some patterns
- mark a comment as FIXME
- whitespace fixes
The PR is independent from from the first part.
resolve: Some refactorings in preparation for uniform paths 2.0
The main result is that in-scope resolution performed during macro expansion / import resolution is now consolidated in a single function (`fn early_resolve_ident_in_lexical_scope`), which can now be used for resolving first import segments as well when uniform paths are enabled.
r? @ghost
Merge `proc_macro_` expansion feature gates as `proc_macro_hygiene`
Merges `proc_macro_mod`, `proc_macro_expr`, `proc_macro_non_items`, and `proc_macro_gen` into a single feature: `proc_macro_hygiene`. These features are not all blocked on implementing macro hygiene *per se*, but rather on interactions with hygiene that have not been entirely resolved.
Changed `BorrowExplanation::UsedLaterWhenDropped` to handle both named
locals and also unnamed (aka temporaries).
If the dropped temporary does not implement `Drop`, then we print its
full type; but when the dropped temporary is itself an ADT `D` that
implements `Drop`, then diagnostic points the user directly at `D`.
This is preparation for allowing the `BorrowExplanation` carry things
like `mir::Location` or `mir::Local` and still be able to generate
usable diagnostic text.
(I found it confusing to have calls to an `emit` method in our
error_reporting module where that `emit` method *wasn't* the
`DiagnosticBuffer::emit` method.)
The restrictions were introduced in https://github.com/rust-lang/rust/pull/54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
std: Start implementing wasm32 atomics
This commit is an initial start at implementing the standard library for
wasm32-unknown-unknown with the experimental `atomics` feature enabled. None of
these changes will be visible to users of the wasm32-unknown-unknown target
because they all require recompiling the standard library. The hope with this is
that we can get this support into the standard library and start iterating on it
in-tree to enable experimentation.
Currently there's a few components in this PR:
* Atomic fences are disabled on wasm as there's no corresponding atomic op and
it's not clear yet what the convention should be, but this will change in the
future!
* Implementations of `Mutex`, `Condvar`, and `RwLock` were all added based on
the atomic intrinsics that wasm has.
* The `ReentrantMutex` and thread-local-storage implementations panic currently
as there's no great way to get a handle on the current thread's "id" yet.
Right now the wasm32 target with atomics is unfortunately pretty unusable,
requiring a lot of manual things here and there to actually get it operational.
This will likely continue to evolve as the story for atomics and wasm unfolds,
but we also need more LLVM support for some operations like custom `global`
directives for this to work best.
adopt "placeholders" to represent universally quantified regions
This does a few preliminary refactorings that lay some groundwork for moving towards universe integration. Two things, primarily:
- Rename from "skolemized" to "placeholder"
- When instantiating `for<'a, 'b, 'c>`, just create one universe for all 3 regions, and distinguish them from one another using the `BoundRegion`.
- This is more accurate, and I think that in general we'll be moving towards a model of separating "binder" (universe, debruijn index) from "index within binder" in a number of places.
- In principle, it feels the current setup of making lots of universes could lead to us doing the wrong thing, but I've actually not been able to come up with an example where this is so.
r? @scalexm
cc @arielb1
