librustc_metadata: Pass a default value when unwrapping a span
Fixes#57323.
When compiling with `static-nobundle` a-la
`rustc -l static-nobundle=nonexistent main.rs`
we now get a neat output in the form of:
```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
|
= help: add #![feature(static_nobundle)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
Better error note on unimplemented Index trait for string
fixes#56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](db53e2e3cd/src/ch08-02-strings.md (indexing-into-strings)) if that PR will get approved :)
Document that `-C opt-level=0` implies `-C debug-assertions`.
I couldn't find it stated anywhere else (https://doc.rust-lang.org/nightly/rustc/codegen-options/index.html#opt-level).
It was a problem before here: https://github.com/rust-lang/rust/issues/39449, it got lost in the migration to the new documentation I assume.
On a sidenote: I think that `-C opt-level=0` having a sideeffect on another flag should be changed. Having compiler flags affecting others doesn't make much sense to me, they are used to fine tune anyway.
In any case, this plays no role in this PR.
Enhance `Pin` impl applicability for `PartialEq` and `PartialOrd`.
This allows for comparing for equality or ordering a `Pin<P>` and a `Pin<Q>` as long as `P` and `Q` are correspondingly comparable themselves *even when `P` and `Q` are different types*.
An example might be comparing a `Pin<&mut OsString>` to a `Pin<&mut PathBuf>`, which might arise from pin projections from a pair of larger contexts that aren't `Unpin`.
Fix sources sidebar not showing up
Fixes#57601.
The order of imports made it so that the sidebar creation was called before the sidebar sources were created. Like this, when the sources are loaded, they create the sidebar as expected.
r? @QuietMisdreavus
Cleanup PartialEq docs.
- Cleanup the `impl PartialEq<BookFormat> for Book` implementation
- Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric
- Fixes https://github.com/rust-lang/rust/issues/53844.
- Removes the last example since it appears to be redundant with the
previous two examples.
Remove confusing comment about ideally using `!` for `c_void`
Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.
In addition document that newtype wrappers around `c_void` can be used
safely in place of `extern type` until the latter is stabilized.
----
I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all?
Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](https://github.com/rust-lang/rust/issues/43467) stabilization ticket seems relevant
> In [std's](164619a8cf/src/libstd/os/raw.rs (L59-L64)) source, it is mentioned that LLVM expects i8* for C's void*.
> We'd need to continue to hack this for the two c_voids in std and libc.
> But perhaps this should be done across-the-board for all extern types?
> Somebody should check what Clang does.
Please correct me if my understanding is wrong and everything's actually fine as is.
rustdoc: Add option to persist doc test executables
Fixes#37048.
This is the initial version of the code so the doctest executables can be used for stuff like code coverage (specifically https://github.com/xd009642/tarpaulin/issues/13) the folders it goes into were just a first idea, so any better ones are welcome.
Right now it creates a directory structure like:
```
given_path/
|_____ <filename>_rs_<linenum>/
|_____ ...
|_____ <filename>_rs_<linenum>/
|_____ rust_out
```
I couldn't figure out where it actually outputs the file w/ the name, I suspect its somewhere deeper in the compiler.
It also adds the unstable `--persist-doctests` flag to `rustdoc` that enables this behavior.
Move spin_loop_hint to core::hint module
As mentioned in #55002. The new name is kept unstable to decide whether the function should have `_hint` in its name.
Prepare beta 1.33.0
This PR includes the usual changes for a new beta, and suppresses a few lints on libcore: those lints are false positives caused by an internal attribute (`rustc_layout_scalar_valid_range_start`) and only happen on stage0.
r? @Mark-Simulacrum
Always calculate glob map but only for glob uses
Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance.
Main motivation is to get rid of some of the moving pieces and simplify the compilation interface - this would allow us to entirely remove `CrateAnalysis`. Later, we could easily expose a relevant query, similar to the likes of `maybe_unused_trait_import` (so using precomputed data from the resolver, but which could be rewritten to be on-demand).
r? @nikomatsakis
Local perf run showed mostly noise (except `ctfe-stress-*`) but I'd appreciate if we could do a perf run run here and double-check that this won't regress performance.
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
rustc: Remove platform intrinsics crate
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
