They were only correct in the simplest case. Some of the optimisations
are certainly possible but should be introduced carefully and only
when the whole pattern codegen infrastructure is in a better shape.
Fixes#16648.
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 */ }
```
Fixes#12643
> Say!
> I like labelled breaks/continues!
I will use them with a `for` loop.
And I will use with a `loop` loop.
Say! I will use them ANYWHERE!
… _even_ in a `while` loop.
Because they're now supported there.
`--pretty expanded,hygiene` is helpful with debugging macro issues,
since two identifiers/names can be textually the same, but different
internally (resulting in weird "undefined variable" errors).
This unifies the `non_snake_case_functions` and `uppercase_variables` lints into one lint, `non_snake_case`. It also now checks for non-snake-case modules. This also extends the non-camel-case types lint to check type parameters, and merges the `non_uppercase_pattern_statics` lint into the `non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case` lint, all non-snake-case variables that start with lowercase characters (such as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the previous `non_snake_case_functions` and `uppercase_variables` lints. All use of the `non_uppercase_pattern_statics` should be replaced with the `non_uppercase_statics` lint. Any code that previously contained non-snake-case module or variable names should be updated to use snake case names or disable the `non_snake_case` lint. Any code with non-camel-case type parameters should be changed to use camel case or disable the `non_camel_case_types` lint.
This also 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`.
[breaking-change]
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`.
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
The inference scheme proposed in <http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-experimental-new-type-inference-scheme-for-rust/>.
This is theoretically a [breaking-change]. It is possible that you may encounter type checking errors, particularly related to closures or functions with higher-ranked lifetimes or object types. Adding more explicit type annotations should help the problem. However, I have not been able to make an example that *actually* successfully compiles with the older scheme and fails with the newer scheme.
f? @pcwalton, @pnkfelix
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
Fixes issue #11943
This squashes the
> `for` loop expression has type `[type error]` which does not implement
> the `Iterator` trait
message that one received when writing `for ... in x` where was
previously found to have a type error.
Fixes#16042.
Eduard Burtescu
bors
nham
Steve Klabnik
Tobba
Jakub Wieczorek
Corey Richardson
Huon Wilson
Alex Crichton
Tshepang Lekhonkhobe
Peter Atashian
wickerwaka
Joseph Martin
P1start
Vinzent Steinberg
Ruud van Asseldonk
Nick Howell
Niko Matsakis
Jonas Hietala
Robert Clipsham
Zbigniew Siciarz
Brian Koropoff
Nick Cameron