Update E0207 label to report parameter type
Fixes#35642.
r? @jonathandturner (Is this okay? I tagged you since it's a simple error fix similar to the other update ones.)
Kicking off libproc_macro
This PR introduces `libproc_macro`, which is currently quite bare-bones (just a few macro construction tools and an initial `quote!` macro).
This PR also introduces a few test cases for it, and an additional `shim` file (at `src/libsyntax/ext/proc_macro_shim.rs` to allow a facsimile usage of Macros 2.0 *today*!
exclude `#![no_builtins]` crates from LTO
this prevents intrinsics like `memcpy` from being mis-optimized to
infinite recursive calls when LTO is used.
fixes#31544closes#35540
---
r? @alexcrichton
cc @Amanieu
Implement the `!` type
This implements the never type (`!`) and hides it behind the feature gate `#[feature(never_type)]`. With the feature gate off, things should build as normal (although some error messages may be different). With the gate on, `!` is usable as a type and diverging type variables (ie. types that are unconstrained by anything in the code) will default to `!` instead of `()`.
Take commandline arguments into account for incr. comp.
Implements the conservative strategy described in https://github.com/rust-lang/rust/issues/33727.
From now one, every time a new commandline option is added, one has to specify if it influences the incremental compilation cache. I've tried to implement this as automatic as possible: One just has to added either the `[TRACKED]` or the `[UNTRACKED]` marker next to the field. The `Options`, `CodegenOptions`, and `DebuggingOptions` definitions in `session::config` show plenty of examples.
The PR removes some cruft from `session::config::Options`, mostly unnecessary copies of flags also present in `DebuggingOptions` or `CodeGenOptions` in the same struct.
One notable removal is the `cfg` field that contained the values passed via `--cfg` commandline arguments. I chose to remove it because (1) its content is only a subset of what later is stored in `hir::Crate::config` and it's pretty likely that reading the cfgs from `Options` would not be what you wanted, and (2) we could not incorporate it into the dep-tracking hash of the `Options` struct because of how the test framework works, leaving us with a piece of untracked but vital data.
It is now recommended (just as before) to access the crate config via the `krate()` method in the HIR map.
Because the `cfg` field is not present in the `Options` struct any more, some methods in the `CompilerCalls` trait now take the crate config as an explicit parameter -- which might constitute a breaking change for plugin authors.
[MIR] Add Storage{Live,Dead} statements to emit llvm.lifetime.{start,end}.
Storage live ranges are tracked for all MIR variables and temporaries with a drop scope.
`StorageLive` is lowered to `llvm.lifetime.start` and `StorageDead` to `llvm.lifetime.end`.
There are some improvements possible here, such as:
* pack multiple storage liveness statements by using the index of first local + `u64` bitset
* enforce that locals are not directly accessed outside their storage live range
* shrink storage live ranges for never-borrowed locals to initialization -> last use
* emit storage liveness statements for *all* temporaries
* however, the remaining ones are *always* SSA immediates, so they'd be noop in MIR trans
* could have a flag on the temporary that its storage is irrelevant (a la C's old `register`)
* would also deny borrows if necessary
* this seems like an overcompliation and with packing & optimizations it may be pointless
Even in the current state, it helps stage2 `rustc` compile `boiler` without overflowing (see #35408).
A later addition fixes#26764 and closes#27372 by emitting `.section` directives for dylib metadata to avoid them being allocated into memory or read as `.note`. For this PR, those bugs were tripping valgrind.
