polymorphization: various improvements
This PR includes a handful of polymorphisation-related changes:
- @Mark-Simulacrum's suggestions [from this comment](https://github.com/rust-lang/rust/pull/74633#issuecomment-668684433):
- Use a `FiniteBitSet<u32>` over a `FiniteBitSet<u64>` as most functions won't have 64 generic parameters.
- Don't encode polymorphisation results in metadata when every parameter is used (in this case, just invoking polymorphisation will probably be quicker).
- @lcnr's suggestion [from this comment](https://github.com/rust-lang/rust/pull/74717#discussion_r463690015).
- Add an debug assertion in `ensure_monomorphic_enough` to make sure that polymorphisation did what we expect.
r? @lcnr
Completes support for coverage in external crates
Follow-up to #74959 :
The prior PR corrected for errors encountered when trying to generate
the coverage map on source code inlined from external crates (including
macros and generics) by avoiding adding external DefIds to the coverage
map.
This made it possible to generate a coverage report including external
crates, but the external crate coverage was incomplete (did not include
coverage for the DefIds that were eliminated.
The root issue was that the coverage map was converting Span locations
to source file and locations, using the SourceMap for the current crate,
and this would not work for spans from external crates (compliled with a
different SourceMap).
The solution was to convert the Spans to filename and location during
MIR generation instead, so precompiled external crates would already
have the correct source code locations embedded in their MIR, when
imported into another crate.
@wesleywiser FYI
r? @tmandry
Update books
## reference
7 commits in b329ce37424874ad4db94f829a55807c6e21d2cb..c9b2736a059469043177e1e4ed41a55d7c63ac28
2020-07-20 08:54:08 -0700 to 2020-08-03 03:34:03 -0700
- Fix documented build output path. (rust-lang-nursery/reference#870)
- Update token usage table. (rust-lang-nursery/reference#868)
- Allow trait inner attributes (rust-lang-nursery/reference#864)
- patterns.md - add word "underscore" to _ paragraph (rust-lang-nursery/reference#865)
- Drive-by mention unsafe fn closure coercion (rust-lang-nursery/reference#802)
- grammar: Change "For awhile" to "For a while" (rust-lang-nursery/reference#857)
- Added Unpin to list of Auto Traits (rust-lang-nursery/reference#854)
## book
7 commits in a914f2c7e5cdb771fa465de142381a51c53b580e..363293c1c5ce9e84ea3935a5e29ce8624801208a
2020-07-21 09:20:05 -0500 to 2020-08-03 15:56:30 -0500
- replace commas with m-dashes to improve readability of chapter 4.1 (rust-lang/book#2419)
- Update TOML link to official website (rust-lang/book#2411)
- Add github repo link (rust-lang/book#2265)
- Remove the version number entirely so we can stop updating it
- Add link to the `Vec<T>` API documentation (rust-lang/book#2249)
- link to stdlib atomic docs (rust-lang/book#2361)
- mdbook version used is now 0.4.x (rust-lang/book#2410)
## rust-by-example
1 commits in 229c6945a26a53a751ffa4f9cb418388c00029d3..2e9271981adc32613365810f3428334c07095215
2020-07-06 10:13:15 -0300 to 2020-07-27 13:39:16 -0500
- Replaced "princess" with "royal" (rust-lang/rust-by-example#1363)
## embedded-book
1 commits in 94d9ea8460bcbbbfef1877b47cb930260b5849a7..b5256448a2a4c1bec68b93c0847066f92f2ff5a9
2020-07-05 14:17:40 +0000 to 2020-07-24 23:09:29 +0000
- Update c-with-rust.md (rust-embedded/book#256)
`run()` returns `Result<(), String>`. But on failure it always returns
an empty string, and then `wrap_return()` treats an empty string
specially, by not reporting the error.
It turns out we already have the `ErrorReported` type for this sort of
behaviour. This commit changes `run()` to use it.
rustdoc's `main()` immediately spawns a thread, M, with a large stack
(16MiB or 32MiB) on which it runs `main_args()`. `main_args()` does a
small amount of options processing and then calls
`setup_callbacks_and_run_in_default_thread_pool_with_globals()`, which
spawns it own thread, and M is not used further.
So, thread M seems unnecessary. However, it does serve a purpose: if the
options processing in `main_args()` panics, that panic is caught when M
is joined. So M can't simply be removed.
However, `main_options()`, which is called by `main_args()`, has a
`catch_fatal_errors()` call within it. We can move that call to `main()`
and change it to the very similar `catch_with_exit_code()`. With that in
place, M can be removed, and panics from options processing will still
be caught appropriately.
Even better, this makes rustdoc's `main()` match rustc's `main()`, which
also uses `catch_with_exit_code()`.
(Also note that the use of a 16MiB/32MiB stack was eliminated from rustc
in #55617.)
Remove the `--no-threads` workaround for wasm targets.
Remove `--no-threads` from the wasm-ld command-line, which was a
workaround for [an old bug] which was fixed in LLVM 9.0, and is
no longer needed.
Also, the `--no-threads` option has been [removed upstream].
[an old bug]: https://bugs.llvm.org/show_bug.cgi?id=41508
[removed upstream]: https://reviews.llvm.org/D76885
r? @alexcrichton
Remove `--no-threads` from the wasm-ld command-line, which was a
workaround for [an old bug] which was fixed in LLVM 9.0, and is
no longer needed.
Also, the `--no-threads` option has been [removed upstream].
[an old bug]: https://bugs.llvm.org/show_bug.cgi?id=41508
[removed upstream]: https://reviews.llvm.org/D76885
This commit adds some debug assertions to `ensure_monomorphic_enough`
which checks that unused generic parameters have been replaced with a
parameter.
Signed-off-by: David Wood <david@davidtw.co>
This commit skips encoding empty polymorphization results - while
polymorphization is disabled, this should be every polymorphization
result; but when polymorphization is re-enabled, this would help with
non-generic functions and those which do use all their parameters (most
functions).
Signed-off-by: David Wood <david@davidtw.co>
The prior PR corrected for errors encountered when trying to generate
the coverage map on source code inlined from external crates (including
macros and generics) by avoiding adding external DefIds to the coverage
map.
This made it possible to generate a coverage report including external
crates, but the external crate coverage was incomplete (did not include
coverage for the DefIds that were eliminated.
The root issue was that the coverage map was converting Span locations
to source file and locations, using the SourceMap for the current crate,
and this would not work for spans from external crates (compliled with a
different SourceMap).
The solution was to convert the Spans to filename and location during
MIR generation instead, so precompiled external crates would already
have the correct source code locations embedded in their MIR, when
imported into another crate.
This commit changes polymorphization to return a `FiniteBitSet<u32>`
rather than a `FiniteBitSet<u64>` because most functions do not use
anywhere near sixty-four generic parameters so keeping a `u64` around is
unnecessary in most cases.
Signed-off-by: David Wood <david@davidtw.co>
Remove two fields from `SubstFolder`.
They're only used in error messages printed if there's an internal
compiler error, and the cost of maintaining them is high enough to show
up in profiles.
r? @matthewjasper
ci: disable fast-fail on auto-fallible
The purpose of the auto-fallible job is to run builders that are likely to fail on CI without gating on them. Having fast-fail enabled there kinda defeats the purpose, as if one of them fails we can't monitor the outcome of the other ones.
This was prompted by the aarch64-gnu builder consistently failing due to a broken test, preventing us from seeing if the macOS spurious failure is fixed.
r? @Mark-Simulacrum
The purpose of the auto-fallible job is to run builders that are likely
to fail on CI without gating on them. Having fail-fast enabled there
kinda defeats the purpose, as if one of them fails we can't monitor the
outcome of the other ones.
This was prompted by the aarch64-gnu builder consistently failing due to
a broken test, preventing us from seeing if the macOS spurious failure
is fixed.
They're only used in error messages printed if there's an internal
compiler error, and the cost of maintaining them is high enough to show
up in profiles.
Make rust.use-lld config option work with non MSVC targets
Builds fine and passes tests on Linux.
Not overriding `use-lld` by `linker` makes sense on those platforms since very old GCC versions don't understand `-fuse-ld=lld`. This allows pointing to newer GCC or Clang that will know how to call LLD.
Rollup of 8 pull requests
Successful merges:
- #74759 (add `unsigned_abs` to signed integers)
- #75043 (rustc_ast: `(Nested)MetaItem::check_name` -> `has_name`)
- #75056 (Lint path statements to suggest using drop when the type needs drop)
- #75081 (Fix logging for rustdoc)
- #75083 (Do not trigger `unused_braces` for `while let`)
- #75084 (Stabilize Ident::new_raw)
- #75103 (Disable building rust-analyzer on riscv64)
- #75106 (Enable docs on in the x86_64-unknown-linux-musl manifest)
Failed merges:
r? @ghost
Enable docs on in the x86_64-unknown-linux-musl manifest
Add the rust-docs component to toolchain x86_64-unknown-linux-musl, which allows people using rustup on their musl-based linux distribution to download the rust-docs.
Generating and uploading the docs was enabled in b5d143b (#74871).
In #75102 @Mark-Simulacrum found that we are uploading the docs, but the correct manifest is missing.
* The relevant call to build-manifest seems to be [in bootstrap](c058a8b8dc/src/bootstrap/dist.rs (L2334))
* The manifest is then used in [promote-release crontab](https://github.com/rust-lang/rust-central-station/blob/master/crontab)
Disable building rust-analyzer on riscv64
riscv64 has an LLVM bug that makes rust-analyzer not build. Should permit future rust-analyzer ups (e.g., https://github.com/rust-lang/rust/pull/74813) to land.
Lint path statements to suggest using drop when the type needs drop
Fixes#48852. With this change the current lint description doesn't really fit entirely anymore I think.
rustc_ast: `(Nested)MetaItem::check_name` -> `has_name`
For consistency with `Attribute::has_name` which doesn't mark the attribute as used either.
Replace all uses of `check_name` with `has_name` outside of rustc, only rustc needs to mark attributes as used.
cc https://github.com/rust-lang/rust/pull/74932
r? @nnethercote
add `unsigned_abs` to signed integers
Mentioned on rust-lang/rfcs#2914
This PR simply adds an `unsigned_abs` to signed integers function which returns the correct absolute value as a unsigned integer.
rustc: Improving safe wasm float->int casts
This commit improves code generation for WebAssembly targets when
translating floating to integer casts. This improvement is only relevant
when the `nontrapping-fptoint` feature is not enabled, but the feature
is not enabled by default right now. Additionally this improvement only
affects safe casts since unchecked casts were improved in #74659.
Some more background for this issue is present on #73591, but the
general gist of the issue is that in LLVM the `fptosi` and `fptoui`
instructions are defined to return an `undef` value if they execute on
out-of-bounds values; they notably do not trap. To implement these
instructions for WebAssembly the LLVM backend must therefore generate
quite a few instructions before executing `i32.trunc_f32_s` (for
example) because this WebAssembly instruction traps on out-of-bounds
values. This codegen into wasm instructions happens very late in the
code generator, so what ends up happening is that rustc inserts its own
codegen to implement Rust's saturating semantics, and then LLVM also
inserts its own codegen to make sure that the `fptosi` instruction
doesn't trap. Overall this means that a function like this:
#[no_mangle]
pub unsafe extern "C" fn cast(x: f64) -> u32 {
x as u32
}
will generate this WebAssembly today:
(func $cast (type 0) (param f64) (result i32)
(local i32 i32)
local.get 0
f64.const 0x1.fffffffep+31 (;=4.29497e+09;)
f64.gt
local.set 1
block ;; label = @1
block ;; label = @2
local.get 0
f64.const 0x0p+0 (;=0;)
local.get 0
f64.const 0x0p+0 (;=0;)
f64.gt
select
local.tee 0
f64.const 0x1p+32 (;=4.29497e+09;)
f64.lt
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
i32.and
i32.eqz
br_if 0 (;@2;)
local.get 0
i32.trunc_f64_u
local.set 2
br 1 (;@1;)
end
i32.const 0
local.set 2
end
i32.const -1
local.get 2
local.get 1
select)
This PR improves the situation by updating the code generation for
float-to-int conversions in rustc, specifically only for WebAssembly
targets and only for some situations (float-to-u8 still has not great
codegen). The fix here is to use basic blocks and control flow to avoid
speculatively executing `fptosi`, and instead LLVM's raw intrinsic for
the WebAssembly instruction is used instead. This effectively extends
the support added in #74659 to checked casts. After this commit the
codegen for the above Rust function looks like:
(func $cast (type 0) (param f64) (result i32)
(local i32)
block ;; label = @1
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
local.tee 1
i32.const 1
i32.xor
br_if 0 (;@1;)
local.get 0
f64.const 0x1.fffffffep+31 (;=4.29497e+09;)
f64.le
i32.eqz
br_if 0 (;@1;)
local.get 0
i32.trunc_f64_u
return
end
i32.const -1
i32.const 0
local.get 1
select)
For reference, in Rust 1.44, which did not have saturating
float-to-integer casts, the codegen LLVM would emit is:
(func $cast (type 0) (param f64) (result i32)
block ;; label = @1
local.get 0
f64.const 0x1p+32 (;=4.29497e+09;)
f64.lt
local.get 0
f64.const 0x0p+0 (;=0;)
f64.ge
i32.and
i32.eqz
br_if 0 (;@1;)
local.get 0
i32.trunc_f64_u
return
end
i32.const 0)
So we're relatively close to the original codegen, although it's
slightly different because the semantics of the function changed where
we're emulating the `i32.trunc_sat_f32_s` instruction rather than always
replacing out-of-bounds values with zero.
There is still work that could be done to improve casts such as `f32` to
`u8`. That form of cast still uses the `fptosi` instruction which
generates lots of branch-y code. This seems less important to tackle now
though. In the meantime this should take care of most use cases of
floating-point conversion and as a result I'm going to speculate that
this...
Closes#73591
