rustbuild: Remove `--enable-llvm-clean-rebuild`
This was intended for bots back in the day where we'd persist caches of LLVM
builds across runs, but nowadays we don't do that on any of the bots so this
option is no longer necessary
save subobligations in the projection cache
The projection cache explicitly chose not to "preserve" subobligations for projections, since the fulfillment context ought to have been doing so. But for the trait evaluation scheme that causes problems. This PR reproduces subobligations. This has the potential to slow down compilation, but minimal investigation suggests it does not do so.
One hesitation about this PR: I could not find a way to make a standalone test case for #43132 (but admittedly I did not try very hard).
Fixes#43132.
r? @arielb1
a couple more error explanations for posterity
E0436, E0595, and moving E0569 to where it belongs in the file rather than being bizarrely out of numerical order
r? @GuillaumeGomez
This was intended for bots back in the day where we'd persist caches of LLVM
builds across runs, but nowadays we don't do that on any of the bots so this
option is no longer necessary
librustc_driver: Remove -Z option from usage on stable compiler
The `-Z` flag has been disabled since Rust 1.19 stable, but it still shows in `rustc --help`.
This PR addresses the inconsistency by removing the message on the stable channel.
We want the error explanations to appear in numerical order so that
they're easy to find. (Also, any other order would be arbitrary and thus
not constitute a Schelling point.) Bizarrely, the extended information
for E0569 was placed between E0244 and E0318 in
librustc_typeck/diagnostics.rs (when the code was introduced in
9a649c32). This commit moves it to be between E0562 and E0570, where it
belongs.
(Also, at reviewer request, say "Erroneous code example", the standard
verbiage that it has been decided that we say everywhere.)
This example focuses on struct-like enum variants, because it's not
immediately obvious in what other context we can get E0436 alone,
without any other, more serious, errors. (Triggering E0436 with a union
also emits a separate "union expressions should have exactly one field"
error.)
(One might argue that we ought to accept the functional record update
syntax for struct-like enums, but that is beyond the scope of this
error-index-comprehensiveness commit.)
rustdoc: print associated types in traits "implementors" section
When viewing a trait's implementors, they won't show anything about the implementation other than any bounds on the generics. You can see the full implementation details on the page for the type, but if the type is external (e.g. it's an extension trait being implemented for primitives), then you'll never be able to see the details of the implementation without opening the source code. This doesn't solve everything about that, but it does still show an incredibly useful piece of information: the associated types. This can help immensely for traits like `Deref` or `IntoIterator` in libstd, and also for traits like `IntoFuture` outside the standard library.
Fixes#24200🚨 BIKESHED ALERT 🚨 The indentation and sizing of the types is suspect. I put it in the small text so it wouldn't blend in with the next impl line. (It shares a CSS class with the where clauses, as you can see in the following image.) However, the indentation is nonstandard. I initially tried with no indentation (looked awkward and blended too well with the surrounding impls) and with 4-space indentation (too easy to confuse with where clauses), before settling on the 2-space indentation seen below. It's... okay, i guess. Open to suggestions.
Flag docker invocations as --privileged on CI
When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were
failing with fatal errors, but they were passing locally when run. Turns out it
looks like they may be using new ptrace-like syscalls so the docker container
now needs `--privileged` when executing to complete the test.
erase types in the move-path abstract domain
Leaving types unerased would lead to 2 types with a different "name"
getting different move-paths, which would cause major brokenness (see
e.g. #42903).
This does not fix any *known* issue, but is required if we want to use
abs_domain with non-erased regions (because the same can easily
have different names). cc @RalfJung.
r? @eddyb
rustdoc: add [src] links to associated functions inside an impl block
While impl blocks currently have a `[src]` link to show the source for the impl block as a whole, individual methods inside that impl block do not. This can pose a problem for structs with a lot of methods, like many in libstd. This change adds little `[src]` links to individual methods that point directly to the function in the bundled source.
fixes#12932
Add Span to ast::WhereClause
This PR adds `Span` field to `ast::WhereClause`. The motivation here is to make rustfmt's life easier when recovering comments before and after where clause.
r? @nrc
When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were
failing with fatal errors, but they were passing locally when run. Turns out it
looks like they may be using new ptrace-like syscalls so the docker container
now needs `--privileged` when executing to complete the test.
Changing E0623 error message - both anonymous lifetime regions
Changing the error message to
```
error[E0623]: lifetime mismatch
--> $DIR/ex3-both-anon-regions.rs:12:12
|
11 | fn foo(x: &mut Vec<&u8>, y: &u8) {
| --- --- these references are not declared with the same lifetime...
12 | x.push(y);
| ^ ...but data from `y` flows into `x` here
error: aborting due to previous error
```
cc @nikomatsakis @aturon @jonathandturner
r? @nikomatsakis
rustbuild: Use Cargo's "target runner"
This commit leverages a relatively new feature in Cargo to execute
cross-compiled tests, the `target.$target.runner` configuration. We configure it
through environment variables in rustbuild and this avoids the need for us to
locate and run tests after-the-fact, instead relying on Cargo to do all that
execution for us.
rustbuild: Update cross-compilers for FreeBSD
When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD
cross compilers we're currently using are unable to build LLVM, failing with
references to the function `std::to_string` claiming it doesn't exist. I don't
actually know what this function is, but assuming that it was added in a more
recent version of a C++ standard I've updated the gcc versions for the
toolchains we're using. This made the error go away!
rustbuild: Tweak how we cross-compile LLVM
In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we
cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to
build libFuzzer which only works on some platforms, and then once we configure
that it needs to apparently reach into the host build area to try to compile
`llvm-config` as well. Once these are both configured, though, it looks like we
can successfully cross-compile LLVM.
Support homogeneous aggregates for hard-float ARM
Hard-float ARM targets use the AAPCS-VFP ABI, which passes and returns
homogeneous float/vector aggregates in the VFP registers.
Fixes#43329.
r? @eddyb
This commit leverages a relatively new feature in Cargo to execute
cross-compiled tests, the `target.$target.runner` configuration. We configure it
through environment variables in rustbuild and this avoids the need for us to
locate and run tests after-the-fact, instead relying on Cargo to do all that
execution for us.
When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD
cross compilers we're currently using are unable to build LLVM, failing with
references to the function `std::to_string` claiming it doesn't exist. I don't
actually know what this function is, but assuming that it was added in a more
recent version of a C++ standard I've updated the gcc versions for the
toolchains we're using. This made the error go away!
In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we
cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to
build libFuzzer which only works on some platforms, and then once we configure
that it needs to apparently reach into the host build area to try to compile
`llvm-config` as well. Once these are both configured, though, it looks like we
can successfully cross-compile LLVM.
Implement tokenization for some items in proc_macro
This PR is a partial implementation of https://github.com/rust-lang/rust/issues/43081 targeted towards preserving span information in attribute-like procedural macros. Currently all attribute-like macros will lose span information with the input token stream if it's iterated over due to the inability of the compiler to losslessly tokenize an AST node. This PR takes a strategy of saving off a list of tokens in particular AST nodes to return a lossless tokenized version. There's a few limitations with this PR, however, so the old fallback remains in place.
This is then later used by `proc_macro` to generate a new
`proc_macro::TokenTree` which preserves span information. Unfortunately this
isn't a bullet-proof approach as it doesn't handle the case when there's still
other attributes on the item, especially inner attributes.
Despite this the intention here is to solve the primary use case for procedural
attributes, attached to functions as outer attributes, likely bare. In this
situation we should be able to now yield a lossless stream of tokens to preserve
span information.
improve case with both anonymous lifetime parameters #43269
This is a fix to #43269.
Sample output message-
```
error[E0623]: lifetime mismatch
--> $DIR/ex3-both-anon-regions.rs:12:12
|
11 | fn foo(x: &mut Vec<&u8>, y: &u8) {
| --- --- these references must have the same lifetime
12 | x.push(y);
| ^ data from `y` flows into `x` here
error: aborting due to 2 previous errors
```
r? @nikomatsakis
This test currently fails because the tokenization of an AST item during the
expansion of a procedural macro attribute rounds-trips through strings, losing
span information.
