It is not required for LLVM to have SPARC target support, so it is
necessary to only run this test when LLVM does support SPARC. Sadly, it
isn’t possible to specify exactly this constraint. Instead, we specify
that this test should run on SPARC host only (it surely is sane
assumption to make that compiler running on a SPARC can generate
SPARC, right?)
Since you cannot specify multiple `only-*` to have it run on both 32-bit
and 64-bit SPARC we pick 64-bit SPARC, because it is exactly what is
being tested by this test.
Fixes#52881
Previously linker diagnostic were being hidden when two modules were linked
together but failed to link. This commit fixes the situation by ensuring that we
have a diagnostic handler installed and also adds support for handling linker
diagnostics.
* Arguably this change is sometimes injecting noise into the output
(namely in the cases where the suggested rewrite is inline with the
suggestion and we end up highlighting the original source code).
I would not be opposed to something more aggressive/dynamic, like
revising the suggestion code to automatically print the original
source when necessary (e.g. when the error does not have a span
that includes the span of the suggestion).
* Also, as another note on this change: The doc comment for `Diagnostic::span_suggestion`
says:
/// The message
///
/// * should not end in any punctuation (a `:` is added automatically)
/// * should not be a question
/// * should not contain any parts like "the following", "as shown"
but the `:` is *not* added when the emitted line appears
out-of-line relative to the suggestion. I find that to be an
unfortunate UI experience.
----
As a drive-by fix, also changed code to combine multiple suggestions
for a pattern into a single multipart suggestion (which vastly
improves user experience IMO).
----
Includes the updates to expected NLL diagnostics.
`const LE_I128` needs parentheses to negate the value *before* calling
`to_le()`, otherwise it doesn't match the operations performed in the
black-boxed part of the test. This only makes a tangible difference on
big-endian targets.
Recent changes to lints disallowed lints from being emitted against code located
in foreign macros, except for future-incompatible lints. For a future
incompatible lint, however, the automatic suggestions may not be applicable!
This commit updates this code path to force all applicability suggestions made
to foreign macros to never be `MachineApplicable`. This should avoid rustfix
actually attempting fixing these suggestions, causing non-compiling code to be
produced.
Closesrust-lang/cargo#5799
Tweak the raw_identifiers lints in 2018
* Enable the `raw_identifiers` feature automatically in the 2018 preview
* Only emit lint warnings if the `raw_identifiers` feature is activated
cc rust-lang/cargo#5783
Add the -Zcrate-attr=foo unstable rustc option
This PR adds a new unstable option to `rustc`: `-Zcrate-attr=foo`. The option can be used to inject crate-level attributes from the CLI, and it's meant to be used by tools like Crater that needs to add their own attributes to a crate without changing the source code.
The exact reason I need this is to implement "edition runs" in Crater: we need to add the preview feature flag to every crate, and editing the crates' source code on the fly might produce unexpected results, while a compiler flag is more reliable.
cc https://github.com/rust-lang-nursery/crater/issues/282 @Mark-Simulacrum
do not overwrite child def-id in place but rather remove/insert
When inserting a node N into the tree of impls, we sometimes find than an existing node C should be replaced with N. We used to overwrite C in place with the new def-id N -- but since the lists of def-ids are separated by simplified type, that could lead to N being inserted in the wrong place. This meant we might miss conflicts. We are now not trying to be so smart -- we remove C and then add N later.
Fixes#52050
r? @aturon -- do you still remember this code at all? :)
Rollup of 11 pull requests
Successful merges:
- #52702 (Suggest fix when encountering different mutability from impl to trait)
- #52703 (Improve a few vectors - calculate capacity or build from iterators)
- #52740 (Suggest underscore when using dashes in crate namet push fork)
- #52759 (Impl Send & Sync for JoinHandle)
- #52760 (rustc_metadata: test loading atoi instead of cos)
- #52763 (Omit the vendor component in Fuchsia triple)
- #52765 (Remove unused "-Zenable_nonzeroing_move_hints" flag)
- #52769 (Incorporate a stray test)
- #52777 (Fix doc comment for 'ptr::copy_to' method)
- #52779 (revert accidental atty downgrade)
- #52781 (Use a slice where a vector is not necessary)
Failed merges:
r? @ghost
[NLL] Use better spans in some errors
* Use the span of the discriminant and patterns for "fake" statements created to properly check matches. I plan to special case these soon, but this felt like a good first step
* Use the span of the statement, rather than the initialization, when reporting move errors for `let x = ...`, which avoids giving an unhelpful suggestion to use `&{ }`.
r? @nikomatsakis cc @pnkfelix
