Different Identifiers and Names can have identical textual representations, but different internal representations, due to the macro hygiene machinery (syntax contexts and gensyms). This provides a way to see these internals by compiling with `--pretty expanded,hygiene`.
This is useful for debugging & hacking on macros (e.g. diagnosing https://github.com/rust-lang/rust/issues/15750/https://github.com/rust-lang/rust/issues/15962 likely would've been faster with this functionality).
E.g.
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
macro_rules! foo {
($x: ident) => { y + $x }
}
fn bar() {
foo!(x)
}
```
```rust
#![feature(macro_rules)]
// minimal junk
#![no_std]
fn bar /* 61#0 */() { y /* 60#2 */ + x /* 58#3 */ }
```
This adds support for lint groups to the compiler. Lint groups are a way of
grouping a number of lints together under one name. For example, this also
defines a default lint for naming conventions, named `bad_style`. Writing
`#[allow(bad_style)]` is equivalent to writing
`#[allow(non_camel_case_types, non_snake_case, non_uppercase_statics)]`. These
lint groups can also be defined as a compiler plugin using the new
`Registry::register_lint_group` method.
This also adds two built-in lint groups, `bad_style` and `unused`. The contents
of these groups can be seen by running `rustc -W help`.
With this change:
* `--pretty variant=<node-id>` will print the item associated with
`<node-id>` (where `<node-id>` is an integer for some node-id in
the AST, and `variant` means one of {`normal`,`expanded`,...}).
* `--pretty variant=<path-suffix>` will print all of the items that
match the `<path-suffix>` (where `<path-suffix>` is a suffix of a
path, and `variant` again means one of {`normal`,`expanded`,...}).
Example 1: the suffix `typeck::check::check_struct` matches the
item with the path `rustc::middle::typeck::check::check_struct`
when compiling the `rustc` crate.
Example 2: the suffix `and` matches `core::option::Option::and`
and `core::result::Result::and` when compiling the `core` crate.
Both of the `--pretty variant=...` modes will include the full path to
the item in a comment that follows the item.
Note that when multiple paths match, then either:
1. all matching items are printed, in series; this is what happens in
the usual pretty-print variants, or
2. the compiler signals an error; this is what happens in flowgraph
printing.
----
Some drive-by improvements:
Heavily refactored the pretty-printing glue in driver.rs, introducing
a couple local traits to avoid cut-and-pasting very code segments that
differed only in how they accessed the `Session` or the
`ast_map::Map`. (Note the previous code had three similar calls to
`print_crate` which have all been unified in this revision; the
addition of printing individual node-ids exacerbated the situation
beyond tolerance.) We may want to consider promoting some of these
traits, e.g. `SessionCarrier`, for use more generally elsewhere in the
compiler; right now I have to double check how to access the `Session`
depending on what context I am hacking in.
Refactored `PpMode` to make the data directly reflect the fundamental
difference in the categories (in terms of printing source-code with
various annotations, versus printing a control-flow graph).
(also, addressed review feedback.)
In a cargo-driven world the primary location for the name of a crate will be in
its manifest, not in the source file itself. The purpose of this flag is to
reduce required duplication for new cargo projects.
This is a breaking change because the existing --crate-name flag actually
printed the crate name. This flag was renamed to --print-crate-name, and to
maintain consistence, the --crate-file-name flag was renamed to
--print-file-name.
To maintain backwards compatibility, the --crate-file-name flag is still
recognized, but it is deprecated.
[breaking-change]
This commit removes all support in the compiler for the #[crate_id] attribute
and all of its derivative infrastructure. A list of the functionality removed is:
* The #[crate_id] attribute no longer exists
* There is no longer the concept of a version of a crate
* Version numbers are no longer appended to symbol names
* The --crate-id command line option has been removed
To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the
crate itself should be mentioned. The version/path of the old crate id should be
removed.
For a transitionary state, the #[crate_id] attribute is still accepted if
the #[crate_name] is not present, but it is warned about if it is the only
identifier present.
RFC: 0035-remove-crate-id
[breaking-change]
We're going to have more modules under lint, and the paths get unwieldy. We
also plan to have lints run at multiple points in the compilation pipeline.
This obsoletes the old `to_err_msg` method. Replace
println!("Error: {}", failure.to_err_msg())
let string = failure.to_err_msg();
with
println!("Error: {}", failure)
let string = failure.to_str();
[breaking-change]
The following features have been removed
* box [a, b, c]
* ~[a, b, c]
* box [a, ..N]
* ~[a, ..N]
* ~[T] (as a type)
* deprecated_owned_vector lint
All users of ~[T] should move to using Vec<T> instead.
This defers to .fatal and .span_fatal for errors (rather than `fail!`
which prints the ICE message). It also adds the span lookup when an id
doesn't correspond to a block, to show what it is pointing at.
It also makes the argument parser slightly looser, so that passing
`--pretty flowgraph` recognises the `flowgraph` part and suggests to use
an integer.
Passing `--pretty flowgraph=<NODEID>` makes rustc print a control flow graph.
In pratice, you will also need to pass the additional option:
`-o <FILE>` to emit output to a `.dot` file for graphviz.
(You can only print the flow-graph for a particular block in the AST.)
----
An interesting implementation detail is the way the code puts both the
node index (`cfg::CFGIndex`) and a reference to the payload
(`cfg::CFGNode`) into the single `Node` type that is used for
labelling and walking the graph. I had once mistakenly thought that I
only wanted the `cfg::CFGNode`, but for labelling, you really want the
cfg index too, rather than e.g. trying to use the `ast::NodeId` as the
label (which breaks down e.g. due to `ast::DUMMY_NODE_ID`).
----
As a drive-by fix, I had to fix `rustc::middle::cfg::construct`
interface to reflect changes that have happened on the master branch
while I was getting this integrated into the compiler. (The next
commit actually adds tests of the `--pretty flowgraph` functionality,
so that should ensure that the `rustc::middle::cfg` code does not go
stale again.)
This adds the flag --color, which allows the user to force coloring or
turn it off. The default behavior stays the same as before (colorize, if
output goes to tty).
Why this is beneficial is explained in issue #12881.
Please note that this commit doesn't include any regression tests. I
thought about how I'd write a test for this and it doesn't seem to be
worth the effort to me for a UI change like this.
Fixes#12881.
The goal of this refactoring is to make the rustc driver code easier to understand and use. Since this is as close to an API as we have, I think it is important that it is nice. On getting stuck in, I found that there wasn't as much to change as I'd hoped to make the stage... fns easier to use by tools.
This patch only moves code around - mostly just moving code to different files, but a few extracted method refactorings too. To summarise the changes: I added driver::config which handles everything about configuring the compiler. driver::session now just defines and builds session objects. I moved driver code from librustc/lib.rs to librustc/driver/mod.rs so all the code is one place. I extracted methods to make emulating the compiler without being the compiler a little easier. Within the driver directory, I moved code around to more logically fit in the modules.
