Replace pretty-print/compare/retokenize hack with targeted workarounds
Based on https://github.com/rust-lang/rust/pull/78296
cc https://github.com/rust-lang/rust/issues/43081
The 'pretty-print/compare/retokenize' hack is used to try to avoid passing an outdated `TokenStream` to a proc-macro when the underlying AST is modified in some way (e.g. cfg-stripping before derives). Unfortunately, retokenizing throws away spans (including hygiene information), which causes issues of its own. Every improvement to the accuracy of the pretty-print/retokenize comparison has resulted in non-trivial ecosystem breakage due to hygiene changes. In extreme cases, users deliberately wrote unhygienic `macro_rules!` macros (likely because they did not realize that the compiler's behavior was a bug).
Additionaly, the comparison between the original and pretty-printed/retoknized token streams comes at a non-trivial runtime cost, as shown by https://github.com/rust-lang/rust/pull/79338
This PR removes the pretty-print/compare/retokenize logic from `nt_to_tokenstream`. We only discard the original `TokenStream` under two circumstances:
* Inner attributes are used (detected by examining the AST)
* `cfg`/`cfg_attr` processing modifies the AST. This is detected by making the visitor update a flag when it performs a modification, instead of trying to detect the modification after-the-fact. Note that a 'matching' `cfg` (e.g. `#[cfg(not(FALSE)]`) does not actually get removed from the AST, allowing us to preserve the original `TokenStream`.
In all other cases, we preserve the original `TokenStream`.
This could use a bit of refactoring/renaming - opening for a Crater run.
r? `@ghost`
Remove `compile-fail` test suite
By moving all of its tests to `ui` test suite.
Now we have directives like `// dont-check-compiler-stderr` that allow to disable `.stderr` comparison for platform-dependent tests without introducing a whole new test suite.
[rustdoc] Box ItemKind to reduce the size of `Item`
This brings the size of `Item` from
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 536
```
to
```
[src/librustdoc/lib.rs:103] std::mem::size_of::<Item>() = 136
```
This is an alternative to https://github.com/rust-lang/rust/pull/79967; I don't think it makes sense to make both changes.
Helps with #79103.
Rollup of 11 pull requests
Successful merges:
- #80383 (clarify wrapping ptr arithmetic docs)
- #80390 (BTreeMap: rename the area access methods)
- #80393 (Add links to the source for the rustc and rustdoc books.)
- #80398 (Use raw version of align_of in rc data_offset)
- #80402 (Document `InferTy` & co.)
- #80403 (fix: small typo error in chalk/mod.rs)
- #80410 (rustdoc book: fix example)
- #80419 (Add regression test for #80375)
- #80430 (Add "length" as doc alias to len methods)
- #80431 (Add "chr" as doc alias to char::from_u32)
- #80448 (Fix stabilization version of deque_range feature.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add "chr" as doc alias to char::from_u32
Many programming languages provide a function called `chr` - Perl, Python, PHP, Visual Basic, SQL. This change makes `char::from_u32` easier to discover in the documentation.
`ord` is not added as its name conflicts with `Ord` trait, and it's not exactly clear what it could point to (`<u32 as From<char>>::from`?). I don't think it's exactly necessary, as `char::from_u32` documentation page says you can do reverse conversion with `as` operator anyway.
Add "length" as doc alias to len methods
Currently when searching for `length` there are no results: https://doc.rust-lang.org/std/?search=length. This makes `len` methods appear when searching for `length`.
Add regression test for #80375
This will also make sure that #80375 is handled if #79135 has to be reverted (which won't happen 🤞).
Closes#80375.
r? `@lcnr`
Document `InferTy` & co.
I finally figured out what `TyVid` means! The name is quite opaque, so I
decided to document it and related types.
I don't know that much about `InferTy` & co., but I was able to *infer*
( :) ) from the names and what I know generally about type inference to
add some basic documentation.
Add links to the source for the rustc and rustdoc books.
This adds a little icon in the upper-right corner of the books so that readers can find the source if they want to make changes or file issues. This is already included in several of the other books.
Rollup of 11 pull requests
Successful merges:
- #79662 (Move some more code out of CodegenBackend::{codegen_crate,link})
- #79815 (Update RELEASES.md for 1.49.0)
- #80284 (Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121)
- #80331 (Add more comments to trait queries)
- #80344 (use matches!() macro in more places)
- #80353 (BTreeMap: test split_off (and append) more thoroughly)
- #80362 (Document rustc_macros on nightly-rustc)
- #80399 (Remove FIXME in rustc_privacy)
- #80408 (Sync rustc_codegen_cranelift)
- #80411 (rustc_span: Remove `Symbol::with`)
- #80434 (bootstrap: put the component name in the tarball temp dir path)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: put the component name in the tarball temp dir path
This should not matter right now, but if we ever parallelize rustbuild this will avoid tarball contents being merged together.
r? `@Mark-Simulacrum`
Sync rustc_codegen_cranelift
The highlight of this sync are two JIT mode improvements. The first is that it is now possible to use JIT mode when using `-Zcodegen-backend` instead of the custom driver using `-Cllvm-args=mode=jit`. The second one is a new JIT mode that lazily compiles functions when they are called the first time: https://github.com/bjorn3/rustc_codegen_cranelift/pull/1120
In addition this includes a few small runtime performance improvements and various fixes for rustc changes that didn't cause compilation to fail.
r? ``@ghost``
``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121
Previously, using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example:
```rust
fn f() -> i32 { 0 }
fn fn_ptr() -> _ { f }
fn closure() -> _ { || 0 }
```
would result in this diagnostic:
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32 {f}`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `[closure@<anon>:3:21: 3:25]`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen, it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally, closures cause a papercut as unique closure types (notated in this case as `[closure@<anon>:3:21: 3:25]`) are not valid syntax either.
Instead, this PR implements this version of the diagnostic (this example is for the same code featured above):
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^ not allowed in type signatures
|
= help: consider using an `Fn`, `FnMut`, or `FnOnce` trait bound
= note: for more information on `Fn` traits and closure types, see https://doc.rust-lang.org/book/ch13-01-closures.html
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen in this diagnostic, the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures, it's suggested to use an `Fn`, `FnMut`, or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment, therefore someone in the future may want to implement that. Also, it's possible to use either `impl Trait` syntax, generics, or generics with a `where` clause, and some users may not want to use `impl Trait` syntax for their own reasons.
This PR fixes#80179.
de-stabilize unsized raw ptr methods for Weak
`@Mark-Simulacrum` this is the patch re: https://github.com/rust-lang/rust/pull/80407.
I couldn't figure out the branch it needs to go on though, stable is still the old stable but beta already the new beta...?
Fix intra-doc links for non-path primitives
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130.
r? `@Manishearth`
cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
Add `impl Div<NonZeroU{0}> for u{0}` which cannot panic
Dividing an unsigned int by a `NonZeroUxx` requires a user to write (for example, in [this SO question](https://stackoverflow.com/questions/64855738/how-to-inform-the-optimizer-that-nonzerou32get-will-never-return-zero)):
```
pub fn safe_div(x: u32, y: std::num::NonZeroU32) -> u32 {
x / y.get()
}
```
which generates a panicking-checked-div [assembly](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:1,lang:rust,selection:(endColumn:2,endLineNumber:6,positionColumn:2,positionLineNumber:6,selectionStartColumn:2,selectionStartLineNumber:6,startColumn:2,startLineNumber:6),source:%27pub+fn+div(x:+u32,+y:+u32)+-%3E+u32+%7B%0A++++x+/+y%0A%7D%0Apub+fn+safe_div(x:+u32,+y:+std::num::NonZeroU32)+-%3E+u32+%7B%0A++++x+/+y.get()+//+an+unchecked+division+expected%0A%7D%27),l:%275%27,n:%270%27,o:%27Rust+source+%231%27,t:%270%27)),k:50,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27),(g:!((h:compiler,i:(compiler:r1470,filters:(b:%270%27,binary:%271%27,commentOnly:%270%27,demangle:%270%27,directives:%270%27,execute:%271%27,intel:%270%27,libraryCode:%271%27,trim:%271%27),fontScale:14,j:1,lang:rust,libs:!(),options:%27-O%27,selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:%275%27,n:%270%27,o:%27rustc+1.47.0+(Editor+%231,+Compiler+%231)+Rust%27,t:%270%27)),k:50,l:%274%27,n:%270%27,o:%27%27,s:0,t:%270%27)),l:%272%27,n:%270%27,o:%27%27,t:%270%27)),version:4).
Avoiding the `panic` currently requires `unsafe` code.
This PR adds an `impl Div<NonZeroU{0}> for u{0}` (and `impl Rem<NonZeroU{0}> for u{0}`) which calls the `unchecked_div` (and `unchecked_rem`) intrinsic without any additional checks,
making the following code compile:
```
pub fn safe_div(x: u32, y: std::num::NonZeroU32) -> u32 {
x / y
}
pub fn safe_rem(x: u32, y: std::num::NonZeroU32) -> u32 {
x % y
}
```
The doc is set to match the regular div impl [docs](https://doc.rust-lang.org/beta/src/core/ops/arith.rs.html#460).
I've marked these as stable because (as I understand it) trait impls are automatically stable. I'm happy to change it to unstable if needed.
Following `@dtolnay` template from a similar issue:
this adds the following **stable** impls, which rely on dividing unsigned integers by nonzero integers being well defined and previously would have involved unsafe code to encode that knowledge:
```
impl Div<NonZeroU8> for u8 {
type Output = u8;
}
impl Rem<NonZeroU8> for u8 {
type Output = u8;
}
```
and equivalent for u16, u32, u64, u128, usize, but **not** for i8, i16, i32, i64, i128, isize (since -1/MIN is undefined).
r? `@dtolnay`
rustdoc: stabilise --default-theme command line option
As discussed in #77213, this seems like it has bedded in and can be safely and usefully made stable.
(rustdoc already has other stable options that interact quite intimately with the rustdoc-supplied CSS, and also an option for supplying entirely different CSS, so exposing the theme names this way seems a very minor step.)
There is also a commit to do some minor grammar fixes to the help message.
