Fix "field is never used" warning to take unions into account
When compiling code containing a union with an unused field, rustc says
"struct field is never used".
Rather than saying "struct or union", or adding logic to determine the
type of the item, just change the message to "field is never used",
dropping the "struct".
Update tests accordingly.
Rather than saying "struct or union" or adding logic to determine the
type of the item, just change the message to "field is never used",
dropping the "struct".
Update tests accordingly.
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #35591: Add a field `span: Span` to `ast::Generics`.
- #35618: Remove variant `Mod` of `ast::PathListItemKind` and refactor the remaining variant `ast::PathListKind::Ident` to a struct `ast::PathListKind_`.
- #35480: Change uses of `Constness` in the AST to `Spanned<Constness>`.
- c.f. `MethodSig`, `ItemKind`
- #35728: Refactor `cx.pat_enum()` into `cx.pat_tuple_struct()` and `cx.pat_path()`.
- #35850: Generalize the elements of lists in attributes from `MetaItem` to a new type `NestedMetaItem` that can represent a `MetaItem` or a literal.
- #35917: Remove traits `AttrMetaMethods`, `AttributeMethods`, and `AttrNestedMetaItemMethods`.
- Besides removing imports of these traits, this won't cause fallout.
- Add a variant `Union` to `ItemKind` to future proof for `union` (c.f. #36016).
- Remove inherent methods `attrs` and `fold_attrs` of `Annotatable`.
- Use methods `attrs` and `map_attrs` of `HasAttrs` instead.
r? @Manishearth
Fix lifetime rules for 'if' conditions
Fixes#12033.
Changes the temporary scope rules to make the condition of an if-then-else a terminating scope. This is a [breaking-change].
Refactor `PathListItem`s
This refactors away variant `Mod` of `ast::PathListItemKind` and refactors the remaining variant `Ident` to a struct `ast::PathListItem_`.
* A step towards #34902
* More stable error messages in some places related to crate loading
* Possible slight performance improvements since all `HashMap`s
replaced had small keys where `FnvHashMap` should be faster
(although I didn't measure)
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
Remove the old AST-based backend from rustc_trans.
Starting with Rust 1.13, `--disable-orbit` , `-Z orbit=off` and `#[rustc_no_mir]` have been removed.
Only the new MIR backend is left in the compiler, and only early const_eval uses ASTs from other crates.
Filling drop (previously "zeroing drop"), `#[unsafe_no_drop_flag]` and associated unstable APIs are gone.
Implementing `Drop` doesn't add a flag anymore to the type, all of the dynamic drop is function local.
This is a [breaking-change], please use `Option::None` and/or `mem::forget` if you are unsure about your ability to prevent/control the drop of a value. In the future, `union` will be usable in some such cases.
**NOTE**: DO NOT MERGE before we get the new beta as the stage0, there's some cruft to remove.
All of this will massively simplify any efforts to implement (and as such it blocks) features such as `union`s, safe use of `#[packed]` or new type layout optimizations, not to mention many other experiments.
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.
Update E0138 to new format
Part of #35233Fix#35510
r? @jonathandturner
Question: How can I only underline the function name ? I have observed the debug output and the struct of item, but I can't find the `Span` for function name. Should I modify the struct I get to save function name's position or there is another way to get it ? (I can only find `Span`s for function attributes, inputs, outputs, blocks)
Commandline arguments influence whether incremental compilation
can use its compilation cache and thus their changes relative to
previous compilation sessions need to be taking into account. This
commit makes sure that one has to specify for every commandline
argument whether it influences incremental compilation or not.
