Because of type inference, duplicate obligations exist and cause duplicate
errors. To avoid this, only display the first error for each (predicate,span).
The inclusion of the span is somewhat bikesheddy, but *is* the more
conservative option (it does not remove some instability, as duplicate
obligations are ignored by `duplicate_set` under some inference conditions).
Fixes#28098
cc #21528 (is it a dupe?)
This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust.
This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor.
The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values.
Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`.
This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :)
r? @alexcrichton
This adds a new target property, `target_vendor` which can be used as a
matcher for conditional compilation. The vendor is part of the autoconf
target triple: <arch><sub>-<vendor>-<os>-<env>
The default value for `target_vendor` is "unknown".
Matching against the `target_vendor` with `#[cfg]` is currently feature
gated as `cfg_target_vendor`.
Fixes#16264 / #18241.
As far as I can tell, it should be impossible for a trait to be inaccessible if it's in scope, so this check is unnecessary. Are there any cases where this check is actually needed?
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
r? @nikomatsakis
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
[breaking-change] for lint authors
You must now implement LateLintPass or EarlyLintPass as well as LintPass and use either register_late_lint_pass or register_early_lint_pass, rather than register_lint_pass.
