This commit finishes work first pioneered in #70458 and started in #71528.
The `-C bitcode-in-rlib` option, which has not yet reached stable, is
renamed to `-C embed-bitcode` since that more accurately reflects what
it does now anyway. Various tests and such are updated along the way as
well.
This'll also need to be backported to the beta channel to ensure we
don't accidentally stabilize `-Cbitcode-in-rlib` as well.
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
submodules: update cargo from 90931d9b3 to 258c89644
Changes:
````
Remove unnecessary loop in `maybe_spurious`
Fix error with git repo discovery and symlinks.
Allow failure when setting file mtime.
Support multiple `--target` flags on the CLI
build-std: Don't treat std like a "local" package.
Allow `cargo package --list` even for things that don't package.
````
I'd like to get https://github.com/rust-lang/cargo/pull/8186 into nightly asap. :)
r? @ehuss
Changes:
````
Remove unnecessary loop in `maybe_spurious`
Fix error with git repo discovery and symlinks.
Allow failure when setting file mtime.
Support multiple `--target` flags on the CLI
build-std: Don't treat std like a "local" package.
Allow `cargo package --list` even for things that don't package.
````
Disable localization for all linkers
We previously disabled non-English output from `link.exe` due to encoding issues (#35785).
In https://github.com/rust-lang/rust/pull/70740 it was pointed out that it also prevents correct inspection of the linker output, which we have to do occasionally.
So this PR disables localization for all linkers.
Have the per-query caches store the results on arenas
This PR leverages the cache for each query to serve as storage area for the query results.
It introduces a new cache `ArenaCache`, which moves the result to an arena,
and only stores the reference in the hash map.
This allows to remove a sizeable part of the usage of the global `TyCtxt` arena.
I only migrated queries that already used arenas before.
Allow `Unreachable` terminators unconditionally in const-checking
If we ever actually reach an `Unreachable` terminator while executing, the MIR is ill-formed or the user's program is UB due to something like `unreachable_unchecked`. I don't think we need to forbid these in `qualify_min_const_fn`.
r? @oli-obk
Allow `Downcast` projections unconditionally in const-checking
`ProjectionElem::Downcast` sounds scary, but it's really just the projection we use to access a particular enum variant. They usually appear in the lowering of a `match` statement, so they have been associated with control flow in const-checking, but they don't do any control flow by themselves. We already have a HIR pass that looks for `if` and `match` (even ones that have 1 or fewer reachable branches). That pass is double-checked by a MIR pass that looks for `SwitchInt`s and `FakeRead`s for match scrutinees. In my opinion, there's no need to look for `Downcast` as well.
r? @oli-obk
MIR dump: print pointers consistently with Miri output
This makes MIR allocation dump pointer printing consistent with Miri output: both use hexadecimal offsets with a `0x` prefix. To save some space, MIR dump replaces the `alloc` prefix by `a` when necessary.
I also made AllocId/Pointer printing more consistent in their Debug/Display handling, and adjusted Display printing for Scalar a bit to avoid using decimal printing when we do not know the sign with which to interpret the value (IMO using decimal then is misleading).
Vec drop and truncate: drop using raw slice *mut [T]
By creating a *mut [T] directly (without going through &mut [T]), avoid
questions of validity of the contents of the slice.
Consider the following risky code:
```rust
unsafe {
let mut v = Vec::<bool>::with_capacity(16);
v.set_len(16);
}
```
The intention is that with this change, we avoid one of the soundness
questions about the above snippet, because Vec::drop no longer
produces a mutable slice of the vector's contents.
r? @RalfJung
Rollup of 5 pull requests
Successful merges:
- #70950 (extend NLL checker to understand `'empty` combined with universes)
- #71433 (Add help message for missing right operand in condition)
- #71449 (Move `{Free,}RegionRelations` and `FreeRegionMap` to `rustc_infer`)
- #71559 (Detect git version before attempting to use --progress)
- #71597 (Rename Unique::empty() -> Unique::dangling())
Failed merges:
r? @ghost
Rename Unique::empty() -> Unique::dangling()
A `FIXME` comment in `src/libcore/ptr/unique.rs` suggested refactoring `Unique::empty()` to `Unique::dangling()` which this PR does.
Detect git version before attempting to use --progress
Otherwise each update is run twice and errors are printed
I've tested this with:
git version 2.8.2.windows.1 (Windows)
git version 2.26.2.266.ge870325ee8 (Linux built from source)
git version 2.17.1 (Linux)
git version 2.21.1 (Apple Git-122.3) (MacOS)
I've tested with Python 2.7 (Windows, Linux, MacOS), 3.6 (Linux), and 3.7 (MacOS)
Move `{Free,}RegionRelations` and `FreeRegionMap` to `rustc_infer`
...and out of `rustc_middle`. This is to further #65031, albeit in a very minor way
r? @Mark-Simulacrum
extend NLL checker to understand `'empty` combined with universes
This PR extends the NLL region checker to understand `'empty` combined with universes. In particular, it means that the NLL region checker no longer considers `exists<R2> { forall<R1> { R1: R2 } }` to be provable. This is work towards https://github.com/rust-lang/rust/issues/59490, but we're not all the way there. One thing in particular it does not address is error messages.
The modifications to the NLL region inference code turned out to be simpler than expected. The main change is to require that if `R1: R2` then `universe(R1) <= universe(R2)`.
This constraint follows from the region lattice (shown below), because we assume then that `R2` is "at least" `empty(Universe(R2))`, and hence if `R1: R2` (i.e., `R1 >= R2` on the lattice) then `R1` must be in some universe that can name `'empty(Universe(R2))`, which requires that `Universe(R1) <= Universe(R2)`.
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
I also made what turned out to be a somewhat unrelated change to add a special region to represent `'empty(U0)`, which we use (somewhat hackily) to indicate well-formedness checks in some parts of the compiler. This fixes#68550.
I did some investigation into fixing the error message situation. That's a bit trickier: the existing "nice region error" code around placeholders relies on having better error tracing than NLL currently provides, so that it knows (e.g.) that the constraint arose from applying a trait impl and things like that. I feel like I was hoping *not* to do such fine-grained tracing in NLL, and it seems like we...largely...got away with that. I'm not sure yet if we'll have to add more tracing information or if there is some sort of alternative.
It's worth pointing out though that I've not kind of shifted my opinion on whose job it should be to enforce lifetimes: I tend to think we ought to be moving back towards *something like* the leak-check (just not the one we *had*). If we took that approach, it would actually resolve this aspect of the error message problem, because we would be resolving 'higher-ranked errors' in the trait solver itself, and hence we wouldn't have to thread as much causal information back to the region checker. I think it would also help us with removing the leak check while not breaking some of the existing crates out there.
Regardless, I think it's worth landing this change, because it was relatively simple and it aligns the set of programs that NLL accepts with those that are accepted by the main region checker, and hence should at least *help* us in migration (though I guess we still also have to resolve the existing crates that rely on leak check for coherence).
r? @matthewjasper
ci: use bash when executing the "bors build finished" jobs
We don't clone the repository in those builders, so the default shell (`src/ci/exec-with-shell.py`) is not present there. This fixes a GHA regression introduced in #71434.
r? @Mark-Simulacrum
Add clarification on std::cfg macro docs v. #[cfg] attribute
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes#71679
Miri: better document and fix dynamic const pattern soundness checks
https://github.com/rust-lang/const-eval/issues/42 got me thinking about soundness for consts being used in patterns, and I found a hole in our existing dynamic checks: a const referring to a mutable static *in a different crate* was not caught. This PR fixes that. It also adds some comments that explain which invariants are crucial for soundness of const-patterns.
Curiously, trying to weaponize this soundness hole failed: pattern matching compilation ICEd when encountering the cross-crate static, saying "expected allocation ID alloc0 to point to memory". I don't know why that would happen, statics *should* be entirely normal memory for pattern matching to access.
r? @oli-obk
Cc @rust-lang/wg-const-eval
Suggest deref when coercing `ty::Ref` to `ty::RawPtr`
Fixes#32122
Currently we do autoderef when casting `ty::Ref` ->`ty::Ref`, but we don't autoderef when casting `ty::Ref` -> `ty::RawPtr`. This PR make the compiler suggests deref when coercing `ty::Ref` to `ty::RawPtr`
rustc: fix check_attr() for methods, closures and foreign functions
This fixes an issue that previously turned up for methods in https://github.com/rust-lang/rust/pull/69274, but also exists for closures and foreign function: `check_attr` does not call `codegen_fn_attrs()` for these types when it should, meaning that incorrectly used function attributes are not diagnosed without codegen.
The issue affects our UI tests, as they run with `--emit=metadata` by default, but as it turns out, this is not the only case: Function attributes are not checked on any dead code without this fix!
This makes the fix a **breaking change**. The following very silly Rust programs compiles fine on stable Rust when it should not, which is fixed by this PR.
```rust
fn main() {
#[target_feature(enable = "sse2")]
|| {};
}
```
I assume any real-world program which may trigger this issue would at least emit a dead code warning, but of course that is no guarantee that such code does not exist...
Fixes#70307
Remove -Z no-landing-pads flag
Since #67502, `-Z no-landing-pads` will cause all attempted unwinds to abort since we don't generate a `try` / `catch`. This previously worked because `__rust_try` was located in libpanic_unwind which is always compiled with `-C panic=unwind`, but `__rust_try` is now directly inline into the crate that uses `catch_unwind`.
As such, `-Z no-landing-pads` is now mostly useless and people should use `-C panic=abort` instead.
Store LLVM bitcode in object files, not compressed
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
Rollup of 6 pull requests
Successful merges:
- #71507 (Document unsafety in core::ptr)
- #71572 (test iterator chain type length blowup)
- #71617 (Suggest `into` instead of `try_into` if possible with int types)
- #71627 (Fix wrong argument in autoderef process)
- #71678 (Add an index page for nightly rustc docs.)
- #71680 (Fix doc link to Eq trait from PartialEq trait)
Failed merges:
- #71597 (Rename Unique::empty() -> Unique::dangling())
r? @ghost
This commit is an attempted resurrection of #70458 where LLVM bitcode
emitted by rustc into rlibs is stored into object file sections rather
than in a separate file. The main rationale for doing this is that when
rustc emits bitcode it will no longer use a custom compression scheme
which makes it both easier to interoperate with existing tools and also
cuts down on compile time since this compression isn't happening.
The blocker for this in #70458 turned out to be that native linkers
didn't handle the new sections well, causing the sections to either
trigger bugs in the linker or actually end up in the final linked
artifact. This commit attempts to address these issues by ensuring that
native linkers ignore the new sections by inserting custom flags with
module-level inline assembly.
Note that this does not currently change the API of the compiler at all.
The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate
whether the bitcode should be present in the object file or not.
Finally, note that an important consequence of this commit, which is also
one of its primary purposes, is to enable rustc's `-Clto` bitcode
loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here
is that when you're building with LTO Cargo will tell rustc to skip
codegen of all intermediate crates and only generate LLVM IR. Today
rustc will generate both object code and LLVM IR, but the object code is
later simply thrown away, wastefully.
The wording was discussed, to a limited degree in #71679. This tries to
address some confusion I as well as someone else had independently when
looking at this macro.
Fixes#71679
Add an index page for nightly rustc docs.
This adds an `index.html` page at the root of the nightly-rustc docs so that the URL https://doc.rust-lang.org/nightly/nightly-rustc/ should have a landing page that lists all the crates.
Fix wrong argument in autoderef process
The `overloaded_deref_ty` is a function for derefencing a type which overloads the `Deref` trait. But actually this function never uses the parameter pushed in until this PR. -_-
Suggest `into` instead of `try_into` if possible with int types
If it is possible to convert an integer type into another using `into`, don't suggest `try_into`. This commit changes the suggested method to convert from one integer type to another for the following cases:
- u{n} -> i{m} where n < m
- u8 -> isize
- i{n} -> isize where n <= 16
- u{n} -> usize where n <= 16
Fixes#71580
Document unsafety in core::ptr
Contributes to #66219
I have yet to document all the `unsafe` blocks in the lib and would like to know if I'm headed in the right direction
r? @steveklabnik
Const qualification for `StructuralEq`
Furthers #62411. Resolves#62614.
The goal of this PR is to implement the logic in #67088 on the MIR instead of the HIR. It uses the `Qualif` trait to track `StructuralPartialEq`/`StructuralEq` in the final value of a `const`. Then, if we encounter a constant during HAIR lowering whose value may not be structurally matchable, we emit the `indirect_structural_match` lint.
This PR contains all the tests present in #67088 and emits the proper warnings for the corner cases. This PR does not handle #65466, which would require that we be [more aggressive](42abbd8878/src/librustc_mir_build/hair/pattern/const_to_pat.rs (L126-L130)) when checking matched types for `PartialEq`. I think that should be done separately.
Because this works on MIR and uses dataflow, this PR should accept more cases than #67088. Notably, the qualifs in the final value of a const are encoded cross-crate, so matching on a constant whose value is defined in another crate to be `Option::<TyWithCustomEqImpl>::None` should work. Additionally, if a `const` has branching/looping, we will only emit the warning if any possible control flow path could result in a type with a custom `PartialEq` impl ending up as the final value of a `const`. I'm not sure how #67088 handled this.
AFAIK, it's not settled that these are the semantics we actually want: it's just how the `Qualif` framework happens to work. If the cross-crate part is undesirable, it would be quite easy to change the result of `mir_const_qualif().custom_eq` to `true` before encoding it in the crate metadata. This way, other crates would have to assume that all publicly exported constants may not be safe for matching.
r? @pnkfelix
cc @eddyb
Change wording on read_vectored docs
Closes#70154
I'm happy to work with others to make the wording on this more clear. I think what I have is an improvement but may not be the final wording.
Suggest `;` or assignment to drop borrows in tail exprs
Address the diagnostics part of #70844.
```
error[E0597]: `counter` does not live long enough
--> $DIR/issue-54556-niconii.rs:22:20
|
LL | if let Ok(_) = counter.lock() { }
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
...
LL | }
| -
| |
| `counter` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>`
|
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | if let Ok(_) = counter.lock() { };
| ^
```
Add documentation example to slice_from_raw_parts_mut()
Add SAFETY explanations to some unsafe blocks in libcore/ptr
* libcore/ptr/mod.rs
* libcore/ptr/unique.rs
* libcore/ptr/non_null.rs
safety-mod.rs: Add SAFETY to slice_from_raw_parts(),
slice_from_raw_parts_mut()
slice_from_raw_parts_mut: Add documentation example
safety-ptr-unique.rs: Add SAFETY to new() and cast()
safety-ptr-non_null.rs: Add SAFETY to new()
safety-ptr-non_null.rs: Add SAFETY to cast()
safety-ptr-non_null.rs: Add SAFETY to from() impls
safety-ptr-unique.rs: Add SAFETY to from() impls
safety-ptr-non_null.rs: Add SAFETY to new()
safety-ptr-unique.rs: Add SAFETY to new()
safety-ptr-mod.rs: Fix safety explanation
https://github.com/rust-lang/rust/pull/71507#discussion_r414488884
safety-prt-non_null.rs: Fix SAFETY comment syntax
safety-ptr-unique.rs: Fix syntax for empty()
safety-ptr-non_null.rs: Fix misuse of non-null for align_of()
safety-ptr-non_null.rs: Remove incorrect SAFETY comment
safety-ptr-unique.rs: Remove unsound SAFETY comment
safety-ptr-mod.rs: Add std comment on slice_from_raw_parts guarantee
safety-ptr-unique.rs: Remove incorrect safety comment
Creating a Unique from a NonNull has strict guarantees that the current
implementation does not guarantee
https://github.com/rust-lang/rust/pull/71507#discussion_r415035952
safety-ptr: Re-adding ignore-tidy directive
Const-prop bugfix: only add propagation inside own block for user variables
A testing spinoff of #71298. This one only adds the const-prop for locals that are user variables.
Address the diagnostics part of #70844.
```
error[E0597]: `counter` does not live long enough
--> $DIR/issue-54556-niconii.rs:22:20
|
LL | if let Ok(_) = counter.lock() { }
| ^^^^^^^-------
| |
| borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
...
LL | }
| -
| |
| `counter` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `std::result::Result<MutexGuard<'_>, ()>`
|
help: consider adding semicolon after the expression so its temporaries are dropped sooner, before the local variables declared by the block are dropped
|
LL | if let Ok(_) = counter.lock() { };
| ^
```
Enable "full tools" option on ARM dist builders
This commit switches the `--enable-extended` option on the arm-related
dist builders to `--enable-full-tools`. This alias in `config.py`
corresponds to enabling a few more options:
* `rust.lld = true` - this is the main purpose of this PR, to enable LLD
on ARM-related platforms. This means it will effectively unlock
compilation of wasm programs from an arm host.
* `rust.llvm-tools = true` - it turns out that this option is largely
ignored in rustbuild today. This is only read in one location to set
some flags for the `llvm-tools` package, but the `llvm-tools` package
is already produced on all of these builders. It's predicted that this
will have no effect on build times.
* `rust.codegen-backends = ['llvm']` - historically this also enabled
the emscripten backend, but that has long since been removed.
This brings the ARM dist builders in line with the x86_64 dist builders
using this flag. The hope is that the extra time spent on CI building
LLD will acceptable because it's cached by `sccache`, LLD is a
relatively small C++ project, and the dist builders are all clocking
well under 3 hours (the slowest of all builders) around 2 hours.
There's likely some possible cleanup that can happen with these
configure options since it doesn't look like they've aged too too well,
but I'm hopeful that possible refactorings, if necessary, could be
deferred to future PRs.
Moving more build-pass tests to check-pass
One or two tests became build-pass without the FIXME because they really
needed build-pass (were failing without it).
Helps with #62277
---
<!-- Reviewable:start -->
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/rust-lang/rust/71340)
<!-- Reviewable:end -->
Rollup of 5 pull requests
Successful merges:
- #71311 (On `FnDef` type annotation suggestion, use fn-pointer output)
- #71488 (normalize field projection ty to fix broken MIR issue)
- #71489 (Fix off by one in treat err as bug)
- #71585 (remove obsolete comment)
- #71634 (Revert #71372 ("Fix #! (shebang) stripping account space issue").)
Failed merges:
r? @ghost
Revert #71372 ("Fix #! (shebang) stripping account space issue").
While #71372 fixed some of the problems `#!`-stripping had, it introduced others:
* inefficient implementation (`.chars().filter(...).collect()` on the entire input file)
* this also means the length returned isn't always correct, leading to e.g. #71471
* it ignores whitespace anywhere, stripping ` # ! ...` which isn't a valid shebang
* the definition of "whitespace" it uses includes newlines, which means even `\n#\n!\n...` is stripped as a shebang (and anything matching the regex `\s*#\s*!\s*`, and not followed by `[`, really)
* it's backward-incompatible but didn't go through Crater
Now, #71487 is already open and will solve all of these issues. But for running Crater, and just in case #71487 takes a bit longer, I decided it's safer to just revert #71372.
This will also make #71372's diff clearer, as it will start again from the original whitespace-unaware version.
r? @petrochenkov
smoke-test for async fn with mir-opt-level=0
MIR opt levels heavily influence which MIR transformations run, and we barely test non-default opt levels. I am particularly worried about `async fn` lowering and how it might (not) work when the set of preceding MIR passes changes -- see https://github.com/rust-lang/rust/pull/70073.
This adds some basic smoke testing, where at least a few `async fn` `run-pass` test are ensured to also work with mir-opt-level=0.
Minimize parameter of coerce_borrowed_pointer()
Change last parameter of `coerce_borrowed_pointer()` from `TypeAndMut` to `Mutability` (similar to `coerce_unsafe_ptr()`), since the `TypeAndMut::ty` is never used directly in this function.
Add Read/Write::can_read/write_vectored
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
0eaf304644/src/proto/h1/io.rs (L582-L594)
If it is possible to convert an integer type into another using
`into`, don't suggest `try_into`. This commit changes the suggested
method to convert from one integer type to another for the following
cases:
- u{n} -> i{m} where n < m
- u8 -> isize
- i{n} -> isize where n <= 16
- u{n} -> usize where n <= 16
Don't run various MIR optimizations at mir-opt-level=0
Add missing checks for mir-opt-level to non-essential MIR passes.
I verified that this can still bootstrap even with these passes disabled.
r? @oli-obk cc @RalfJung
New lint `match_vec_item`
Added new lint to warn a match on index item which can panic. It's always better to use `get(..)` instead.
Closes#5500
changelog: New lint `match_on_vec_items`
submodules: update clippy from 891e1a85 to d01a4981
Changes:
````
`predecessors_for` will be removed soon
Rustup "Remove `BodyAndCache`"
span_lint_and_note now takes an Option<Span> for the note_span instead of just a span
Make lint also capture blocks and closures, adjust language to mention other mutex types
don't test the code in the lint docs
Switch to matching against full paths instead of just the last element of the path
Lint for holding locks across await points
fix crash on issue-69020-assoc-const-arith-overflow.rs
update stderr file
util/fetch_prs_between.sh: Add Markdown formatted Link
factor ifs into function, add differing mutex test
Update the changelog update documentation
Apply suggestions from PR review
update span_lint_and_help call to six args
test for mutex eq, add another test case
use if chain
cargo dev fmt
fix map import to rustc_middle
dev update_lints
fix internal clippy warnings
change visitor name to OppVisitor
use Visitor api to find Mutex::lock calls
add note about update-all-refs script, revert redundant pat to master
move closures to seperate fns, remove known problems
use span_lint_and_help, cargo dev fmt
creating suggestion
progress work on suggestion for auto fix
Implement unsafe_derive_deserialize lint
Update empty_enum.stderr
Formatting and naming
Formatting and naming
Cleanup: `node_id` -> `hir_id`
Fix issue #2907.
Don't trigger toplevel_ref_arg for `for` loops
Cleanup: future_not_send: use `return_ty` method
Remove badge FIXME from Cargo.toml
Change note_span argument for span_lint_and_note.
Add an Option<Span> argument to span_lint_and_help.
Fixes internal lint warning in code base.
Implement collapsible_span_lint_calls lint.
````
Fixes#71453
r? @Dylan-DPC
Minor refactoring around IndexVec usage in generator transformation
Replace hash map with IndexVec for liveness data.
Utilize IndexVec::push return value to avoid redundant object creation.
r? @eddyb
Remove support for self-opening
This was only used for linkage test cases, which is already covered by
the [run-make-fulldeps/symbol-visibility test](https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/symbol-visibility/Makefile) -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
This fixes#10379 and resolves#10356 by removing the test case (and underlying support in the compiler). AFAICT, the better way to test visibility is via nm, like the symbol visibility test. It seems like that's sufficient; I suspect that given that we don't use this we should just drop it (android is tier 2 anyway). But happy to hear otherwise.
Add a function to turn Box<T> into Box<[T]>
Hi,
I think this is very useful, as currently it's not possible in safe rust to do this without re-allocating.
an alternative implementation of the same function can be:
```rust
pub fn into_boxed_slice<T>(boxed: Box<T>) -> Box<[T]> {
unsafe {
let slice = slice::from_raw_parts_mut(Box::into_raw(boxed), 1);
Box::from_raw(slice)
}
}
```
The only thing that makes me a little uncomfortable is this line :
> The alignment of array types is greater or equal to the alignment of its element type
from https://rust-lang.github.io/unsafe-code-guidelines/layout/arrays-and-slices.html
But then I see:
> The alignment of &T, &mut T, *const T and *mut T are the same, and are at least the word size.
> The alignment of &[T] is the word size.
from https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html#representation
So I do believe this is valid(FWIW it also passes in miri https://play.rust-lang.org/?gist=c002b99364ee6b29862aeb3565a91c19)
