std: Inline some Termination-related methods
These were showing up in tests and in binaries but are trivially optimize-able
away, so add `#[inline]` attributes so LLVM has an opportunity to optimize them
out.
A span covering a single byte, such as for an operator `+` token, should
print as e.g. `80..81` rather than `80...81`. The lo end of the range is
inclusive and the hi end is exclusive.
Print query stack on ICEs
ICE output is now:
```
thread 'rustc' panicked at 'no borrowck', librustc_borrowck\borrowck\mod.rs:95:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
query stack during panic:
#0 [borrowck] processing `main`
--> no-std.rs:10:1
|
10 | fn main() {}
| ^^^^^^^^^
end of query stack
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.26.0-dev running on x86_64-pc-windows-msvc
```
Fixes#42529.
r? @eddyb
This commit improves the `fmt::Debug` output of `proc_macro` data structures by
primarily focusing on the representation exposed by `proc_macro` rather than the
compiler's own internal representation. This cuts down quite a bit on assorted
wrapper types and ensure a relatively clean output.
Closes#49720
rustdoctest: suppress the default allow(unused) under --display-warnings
If you're passing rustdoc `--display-warnings`, you probably want to see the default ones too. This change modifies `test::make_test` to suppress the default `#![allow(unused)]` if the `--display-warnings` CLI flag was provided to rustdoc.
cc https://github.com/rust-lang/rust/issues/41574
Allow for re-using monomorphizations in upstream crates.
Followup to #48611. This implementation is pretty much finished modulo failing tests if there are any. Not quite ready for review yet though.
### DESCRIPTION
This PR introduces a `share-generics` mode for RLIBs and Rust dylibs. When a crate is compiled in this mode, two things will happen:
- before instantiating a monomorphization in the current crate, the compiler will look for that monomorphization in all upstream crates and link to it, if possible.
- monomorphizations are not internalized during partitioning. Instead they are added to the list of symbols exported from the crate.
This results in less code being translated and LLVMed. However, there are also downsides:
- it will impede optimization somewhat, since fewer functions can be internalized, and
- Rust dylibs will have bigger symbol tables since they'll also export monomorphizations.
Consequently, this PR only enables the `shared-generics` mode for opt-levels `No`, `Less`, `Size`, and `MinSize`, and for when incremental compilation is activated. `-O2` and `-O3` will still generate generic functions per-crate.
Another thing to note is that this has a somewhat similar effect as MIR-only RLIBs, in that monomorphizations are shared, but it is less effective because it cannot share monomorphizations between sibling crates:
```
A <--- defines `fn foo<T>() { .. }`
/ \
/ \
B C <--- both call `foo<u32>()`
\ /
\ /
D <--- calls `foo<u32>()` too
```
With `share-generics`, both `B` and `C` have to instantiate `foo<u32>` and only `D` can re-use it (from either `B` or `C`). With MIR-only RLIBs, `B` and `C` would not instantiate anything, and in `D` we would then only instantiate `foo<u32>` once.
On the other hand, when there are many leaf crates in the graph (e.g. when compiling many individual test binaries) then the `share-generics` approach will often be more effective.
### TODO
- [x] Add codegen test that makes sure monomorphizations can be internalized in non-Rust binaries.
- [x] Add codegen-units test that makes sure we share generics.
- [x] Add run-make test that makes sure we don't export any monomorphizations from non-Rust binaries.
- [x] Review for reproducible-builds implications.
AST: Give spans to all identifiers
Change representation of `ast::Ident` from `{ name: Symbol, ctxt: SyntaxContext }` to `{ name: Symbol, span: Span }`.
Syntax contexts still can be extracted from spans (`span.ctxt()`).
Why this should not require more memory:
- `Span` is `u32` just like `SyntaxContext`.
- Despite keeping more spans in AST we don't actually *create* more spans, so the number of "outlined" spans kept in span interner shouldn't become larger.
Why this may be slightly slower:
- When we need to extract ctxt from an identifier instead of just field read we need to do bit field extraction possibly followed by and access by index into span interner's vector. Both operations should be fast (unless the span interner is under some synchronization) and we already do ctxt extraction from spans all the time during macro expansion, so the difference should be lost in noise.
cc https://github.com/rust-lang/rust/pull/48842#issuecomment-373365661
kennytm
David Tolnay
bors
Shotaro Yamada
Alex Crichton
Pulkit Goyal
bobtwinkles
Tyler Mandry
gaurikholkar
Jorge Aparicio
John Kåre Alsaker
Michael Woerister
Vadim Petrochenkov