incr.comp.: Track expanded spans instead of FileMaps.
This PR removes explicit tracking of FileMaps in response to #42101. The reasoning behind being able to just *not* track access to FileMaps is similar to why we don't track access to the `DefId->DefPath` map:
1. One can only get ahold of a `Span` value by accessing the HIR (for local things) or a `metadata::schema::Entry` (for things from external crates).
2. For both of these things we compute a hash that incorporates the *expanded spans*, that is, what we hash is in the (FileMap independent) format `filename:line:col`.
3. Consequently, everything that emits a span should already be tracked via its dependency to something that has the span included in its hash and changes would be detected via that hash.
One caveat here is that we have to be conservative when exporting things in metadata. A crate can be built without debuginfo and would thus by default not incorporate most spans into the metadata hashes. However, a downstream crate can make an inline copy of things in the upstream crate and span changes in the upstream crate would then go undetected, even if the downstream uses them (e.g. by emitting debuginfo for an inlined function). For this reason, we always incorporate spans into metadata hashes for now (there might be more efficient ways to handle this safely when red-green tracking is implemented).
r? @nikomatsakis
Override size_hint and propagate ExactSizeIterator for iter::StepBy
Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`.
A small non-breaking subset of https://github.com/rust-lang/rust/pull/42110 (which I closed).
Includes two small documentation changes @ivandardi requested on that PR.
r? @alexcrichton
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
This fixes leakage on panic with arrays & slices. I am using a C-style
for-loop instead of a pointer-based loop because that would be ugly-er
to implement.
Remove unused APIs from rustc_trans
There were public re-exports of some rustc modules dating back to 2011 or so. While I was at it, some functions and modules were public but never used outside the crate. I made them private or `pub(crate)` as appropriate and in one case removed an unused function.
Docs: impls of PartialEq/PartialOrd/Ord must agree
Fixes#41270.
This PR brings two improvements to the docs:
1. Docs for `PartialEq`, `PartialOrd`, and `Ord` clarify that their implementations must agree.
2. Fixes a subtle bug in the Dijkstra example for `BinaryHeap`, where the impls are inconsistent.
Thanks @Rufflewind for spotting the bug!
r? @alexcrichton
cc @frankmcsherry
extend `struct_tail` to operate over tuples
Not 100% sure why this got exposed when it wasn't before, but this struct definitely seems wrong.
Fixes#42110
r? @eddyb
Update to Rc and Arc documentation to favor the Rc::clone(&ptr) syntax.
This is a followup of the discussion in https://github.com/rust-lang/rfcs/pull/1954.
The solution chosen by the core team to address the problem tackled by the [the RFC](https://github.com/rust-lang/rfcs/pull/1954) was to make the function call syntax Rc::clone(&foo) the idiomatic way to clone a reference counted pointer (over the method call syntax foo.clone()).
This change updates the documentation of Rc, Arc and their respective Weak pointers to reflect this decision and bring more exposure to the existence of the function call syntax.
Mark various items and fields as private or pub(crate), and remove a function that turns out to be unused.
These are not used anywhere in-tree, but I guess it's a [breaking-change] for plugins.
trace_macro: Show both the macro call and its expansion. #42072.
See #42072 for the initial motivation behind this.
The change is not the minimal fix, but I want this behavior almost every time I use `trace_macros`.
rustbuild: don't create a source tarball when installing
This splits Install out of Dist as it is not a full dist anymore, and creates the source tarball only for the Dist command.
This will allow splitting install in a few rules if we want as it's done for other phases.
Use the improved submodule handling
r? @alexcrichton
That was a crap...
```
Updating submodules
Traceback (most recent call last):
File "./x.py", line 20, in <module>
bootstrap.main()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 684, in main
bootstrap()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 662, in bootstrap
rb.update_submodules()
File "/home/ishitatsuyuki/Documents/rust/src/bootstrap/bootstrap.py", line 566, in update_submodules
path = line[1:].split(' ')[1]
TypeError: a bytes-like object is required, not 'str'
```
Maybe we need to confirm the compatibility of git options, such as `git config` or `git -C` (I believe they existed long before, though). This is tested locally.
Fix 'associate type' typo
I came across an error message mentioning an 'associate type'.
Since this is the only instance of this term in rustc (it's 'associated type' everywhere else), I think this might be a typo.
Make assignments to `Copy` union fields safe
This is an accompanying PR to PR https://github.com/rust-lang/rust/pull/42068 stabilizing FFI unions.
This was first proposed in https://github.com/rust-lang/rust/issues/32836#issuecomment-281296416, see subsequent comments as well.
Assignments to `Copy` union fields do not read any data from the union and are [equivalent](https://github.com/rust-lang/rust/issues/32836#issuecomment-281660298) to whole union assignments, which are safe, so they should be safe as well. This removes a significant number of "false positive" unsafe blocks, in code dealing with FFI unions in particular.
It desirable to make this change now, together with stabilization of FFI unions, because now it affecfts only unstable code, but later it will cause warnings/errors caused by `unused_unsafe` lint in stable code.
cc #32836
r? @nikomatsakis
add thiscall calling convention support
This support is needed for bindgen to work well on 32-bit Windows, and also enables people to begin experimenting with C++ FFI support on that platform.
Fixes#42044.
