Before, the identifier `X` was also used when generating a pattern
to match against the dep-node. So `Foo(DefId)` would generate a match
pattern like:
match foo {
Foo(DefId) => ...
}
This does not scale to more general types like `&'tcx
Ty<'tcx>`. Therefore, we now require *exactly one* argument (the macro
was internally tupling anyway, and no actual nodes use more than one
argument), and then we can generate a fixed pattern like:
match foo {
Foo(arg) => ...
}
Huzzah. (Also, hygiene is nice.)
In general, we've been moving towards a semantics where you can have
contradictory where-clauses, and we try to honor them. There are
already existing run-pass tests where we take that philosophy as
well (e.g., `compile-fail/issue-36839.rs`). The current behavior of
`and`, where it strips the environment, breaks that code.
- `ParamEnv::empty()` -- does not reveal all, good for typeck
- `ParamEnv::reveal_all()` -- does, good for trans
- `param_env.with_reveal_all()` -- converts an existing parameter environment
Improvements:
- Use Clone not Copy for the "simple cases"
- Separate TypeFoldable and Lift for the "simple cases"
- Support generics type parameters
- Support named fields in enum variants
- etc
Warn about ignored generic bounds in `for`
This adds a new lint to fix#42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
rustc: Fix ICE with `#[target_feature]` on module
This commit fixes an ICE in rustc when `#[target_feature]` was applied to items
other than functions due to the way the feature was validated.
