rustc_metadata: Some reorganization of the module structure
The new structure of `rustc_metadata` (or rather its parts affected by the refactoring) is
```
├── lib.rs
└── rmeta
├── decoder
│ └── cstore_impl.rs
├── decoder.rs
├── encoder.rs
├── mod.rs
└── table.rs
```
(`schema` is renamed to `rmeta`.)
The code inside `rmeta` is pretty self-contained, so we can now privatize almost everything in this module instead of using `pub(crate)` which was necessary when all these modules accessed their neighbors in the old flat structure.
`encoder` and `decoder` work with structures defined by `rmeta`.
`table` is a part of `rmeta`.
`cstore_impl` actively uses decoder methods and exposes their results through very few public methods (`provide` and `_untracked` methods).
r? @eddyb @spastorino
consistent handling of missing sysroot spans
Due to https://github.com/rust-lang/rust/issues/53081, sysroot spans (pointing to code in libcore/libstd/...) fails to print on some x86 runners. This consolidates the ignore directives for that and references the relevant issue.
I also did that for the generated derive-error-span tests -- but there the script and the tests were not entirely in sync any more since https://github.com/rust-lang/rust/pull/64151. Cc @estebank @varkor
Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`
Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers.
All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics.
Example:
```rust
use std::mem::MaybeUninit;
let input = b"Foo";
let f = u8::to_ascii_uppercase;
let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array();
let vec;
let output = if let Some(buffer) = buffer.get_mut(..input.len()) {
buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); });
unsafe { MaybeUninit::slice_get_ref(buffer) }
} else {
vec = input.iter().map(f).collect::<Vec<u8>>();
&vec
};
assert_eq!(output, b"FOO");
```
Enhance the documentation of BufReader for potential data loss
This is (IMO) and enhancement of the `std::io::BufReader` documentation, that aims to highlight how relatively easy is to end up with data loss when improperly using an instance of this class.
This is following the issue I had figuring out why my application was loosing data, because I focused my attention on the word *multiple instances* of `BufReader` in its `struct` documentation, even if I ever only had one instance.
Link to the issue: https://github.com/tokio-rs/tokio/issues/1662
Stabilize --extern flag without a path.
This stabilizes the `--extern` flag without a path, implemented in #54116.
This flag is used to add a crate that may be found in the search path to the extern prelude. The intent of stabilizing this now is to change Cargo to emit this flag for `proc_macro` when building a proc-macro crate. This will allow the ability to elide `extern crate proc_macro;` for proc-macros, one of the few places where it is still necessary.
It is intended that Cargo may also use this flag for other cases in the future as part of the [std-aware work](https://github.com/rust-lang/wg-cargo-std-aware/). There will likely be some kind of syntax where users may declare dependencies on other crates (such as `alloc`), and Cargo will use this flag so that they may be used like any other crate. At this time there are no short-term plans to use it for anything other than proc-macro.
This will not help for non-proc-macro crates that use `proc_macro`, which I believe is not too common?
An alternate approach for proc-macro is to use the `meta` crate, but from my inquiries there doesn't appear to be anyone interested in pushing that forward. The `meta` crate also doesn't help with things like `alloc` or `test`.
cc #57288
Rollup of 5 pull requests
Successful merges:
- #63793 (Have tidy ensure that we document all `unsafe` blocks in libcore)
- #64696 ([rustdoc] add sub settings)
- #65916 (syntax: move stuff around)
- #66087 (Update some build-pass ui tests to use check-pass where applicable)
- #66182 (invalid_value lint: fix help text)
Failed merges:
r? @ghost
Currently the `RUST_CONFIGURE_ARGS` variable apparently has a trailing
newline at the end of it due to the way it's configured in yaml. This
causes issues with MSVC's `install-clang.sh` step where the way the bash
syntax works out means that we drop the arg we're trying to add and it
doesn't actually get added!
The hopeful fix here is to tweak how we specify the yaml syntax to not
have a trailing newline, we'll see what CI says about this...
invalid_value lint: fix help text
Now that we also warn about `MaybUninit::uninit().assume_init()`, just telling people "use `MaybeUninit`" isn't always sufficient. And anyway this seems like an important enough point to mention it here.
Have tidy ensure that we document all `unsafe` blocks in libcore
cc @rust-lang/libs
I documented a few and added ignore flags on the other files. We can incrementally document the files, but won't regress any files this way.
Add future incompatibility lint for `array.into_iter()`
This is for #65819. This lint warns when calling `into_iter` on an array directly. That's because today the method call resolves to `<&[T] as IntoIterator>::into_iter` but that would change when adding `IntoIterator` impls for arrays. This problem is discussed in detail in #65819.
We still haven't decided how to proceed exactly, but it seems like adding a lint is a good idea regardless?
Also: this is the first time I implement a lint, so there are probably a lot of things I can improve. I used a different strategy than @scottmcm describes [here](https://github.com/rust-lang/rust/pull/65819#issuecomment-548667847) since I already started implementing this before they commented.
### TODO
- [x] Decide if we want this lint -> apparently [we want](https://github.com/rust-lang/rust/pull/65819#issuecomment-548964818)
- [x] Open a lint-tracking-issue and add the correct issue number in the code -> https://github.com/rust-lang/rust/issues/66145
A scheme for more macro-matcher friendly pre-expansion gating
Pre-expansion gating will now avoid gating macro matchers that did not result in `Success(...)`. That is, the following is now OK despite `box 42` being a valid `expr` and that form being pre-expansion gated:
```rust
macro_rules! m {
($e:expr) => { 0 }; // This fails on the input below due to `, foo`.
(box $e:expr, foo) => { 1 }; // Successful matcher, we should get `2`.
}
fn main() {
assert_eq!(1, m!(box 42, foo));
}
```
Closes https://github.com/rust-lang/rust/issues/65846.
r? @petrochenkov
cc @Mark-Simulacrum
