Guillaume Gomez [Tue, 18 May 2021 12:08:42 +0000 (14:08 +0200)]
Rollup merge of #85280 - jsha:move-trait-toggles, r=GuillaumeGomez
Toggle-wrap items differently than top-doc.
This makes sure things like trait methods get wrapped at the
`<h3><code>` level rather than at the `.docblock` level. Also it ensures
that only the actual top documentation gets the `.top-doc` class.
Guillaume Gomez [Tue, 18 May 2021 12:08:41 +0000 (14:08 +0200)]
Rollup merge of #84587 - jyn514:rustdoc-lint-block, r=CraftSpider
rustdoc: Make "rust code block is empty" and "could not parse code block" warnings a lint (`INVALID_RUST_CODEBLOCKS`)
Fixes https://github.com/rust-lang/rust/issues/79792. This already went through FCP in https://github.com/rust-lang/rust/pull/79816, so it only needs final review.
This is mostly a rebase of https://github.com/rust-lang/rust/pull/79816 - thank you ``@poliorcetics`` for doing most of the work!
bors [Tue, 18 May 2021 08:01:32 +0000 (08:01 +0000)]
Auto merge of #82973 - ijackson:exitstatuserror, r=yaahc
Provide ExitStatusError
Closes #73125
In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics.
I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
Alexis Bourget [Mon, 28 Dec 2020 22:07:20 +0000 (23:07 +0100)]
New rustdoc lint to respect -Dwarnings correctly
This adds a new lint to `rustc` that is used in rustdoc when a code
block is empty or cannot be parsed as valid Rust code.
Previously this was unconditionally a warning. As such some
documentation comments were (unknowingly) abusing this to pass despite
the `-Dwarnings` used when compiling `rustc`, this should not be the
case anymore.
bors [Mon, 17 May 2021 19:15:21 +0000 (19:15 +0000)]
Auto merge of #85414 - RalfJung:rollup-ueqcik4, r=RalfJung
Rollup of 8 pull requests
Successful merges:
- #85087 (`eval_fn_call`: check the ABI of `body.source`)
- #85302 (Expand WASI abbreviation in docs)
- #85355 (More tests for issue-85255)
- #85367 (Fix invalid input:disabled CSS selector)
- #85374 (mark internal inplace_iteration traits as hidden)
- #85408 (remove size field from Allocation)
- #85409 (Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`)
- #85412 (remove some functions that were only used by Miri)
Ralf Jung [Mon, 17 May 2021 16:52:13 +0000 (18:52 +0200)]
Rollup merge of #85409 - CDirkx:cfg_redox, r=nagisa
Simplify `cfg(any(unix, target_os="redox"))` in example to just `cfg(unix)`
Update example for `OsString` that handled `redox` seperately from `unix`: Redox has been completely integrated under `target_family="unix"`, so `cfg(unix)` implies `target_os="redox"`
Ralf Jung [Mon, 17 May 2021 16:52:04 +0000 (18:52 +0200)]
Rollup merge of #85302 - r00ster91:patch-7, r=joshtriplett
Expand WASI abbreviation in docs
I was pretty sure this was related to something for WebAssembly but wasn't 100% sure so I checked but even on these top-level docs I couldn't find the abbreviation expanded. I'm normally used to Rust docs being detailed and explanatory and writing abbreviations like this out in full at least once so I thought it was worth the change. Feel free to close this if it's too much.
Ralf Jung [Mon, 17 May 2021 16:51:59 +0000 (18:51 +0200)]
Rollup merge of #85087 - hyd-dev:lots-of-abis, r=RalfJung
`eval_fn_call`: check the ABI of `body.source`
And stop checking `instance_ty.fn_sig(*self.tcx).abi()`, if the function is not an intrinsic.
Addresses https://github.com/rust-lang/miri/pull/1776#discussion_r615381169.
No idea how to test this without Miri...
bors [Mon, 17 May 2021 16:34:11 +0000 (16:34 +0000)]
Auto merge of #85352 - Xanewok:update-rls, r=Xanewok
Update RLS
Contains https://github.com/rust-lang/rls/pull/1736. With #82208 merged, this should now close https://github.com/rust-lang/rust/issues/85225. Tested locally with `./x.py test src/tools/rls` and seems to be working as expected.
I noticed the rustfmt merge didn't trigger toolstate upgrade (because we pruned most but not all of the related machinery?), so I'd rather get this rubber-stamped by someone more knowledgeable with infra/the merged changes in case I missed something and need to include something else here to unbreak the RLS toolstate.
bors [Sun, 16 May 2021 23:00:53 +0000 (23:00 +0000)]
Auto merge of #84993 - eddyb:cg-ssa-on-demand-blocks, r=nagisa
rustc_codegen_ssa: only create backend `BasicBlock`s as-needed.
Instead of creating one backend (e.g. LLVM) block per MIR block ahead of time, and then deleting the ones that weren't visited, this PR moves to creating the blocks as they're needed (either reached via the RPO visit, or used as the target of a branch from a different block).
As deleting a block was the only `unsafe` builder method (generally we only *create* backend objects, not *remove* them), that's gone now and codegen is overall a bit safer.
The only change in output is the order of LLVM blocks (which AFAIK has no semantic meaning, other than the first block being the entry block). This happens because the blocks are now created due to control-flow edges, rather than MIR block order.
I'm making this a standalone PR because I keep getting wild perf results when I change *anything* in codegen, but if you want to read more about my plans in this area, see https://github.com/rust-lang/rust/pull/84771#issuecomment-830636256 (and https://github.com/rust-lang/rust/pull/84771#issue-628295651 - but that may be a bit outdated).
(You may notice some of the APIs in this PR, like `append_block`, don't help with the future plans - but I didn't want to include the necessary refactors that pass a build around everywhere, in this PR, so it's a small compromise)
bors [Sun, 16 May 2021 20:19:45 +0000 (20:19 +0000)]
Auto merge of #85312 - ehuss:macro_use-unused-attr, r=petrochenkov
Fix unused attributes on macro_rules.
The `unused_attributes` lint wasn't firing on attributes of `macro_rules` definitions. The consequence is that many attributes are silently ignored on `macro_rules`. The reason is that `unused_attributes` is a late-lint pass, and only has access to the HIR, which does not have macro_rules definitions.
My solution here is to change `non_exported_macro_attrs` to be `macro_attrs` (a list of all attributes used for `macro_rules`, instead of just those for `macro_export`), and then to check this list in the `unused_attributes` lint. There are a number of alternate approaches, but this seemed the most reliable and least invasive. I am open to completely different approaches, though.
One concern is that I don't fully understand the implications of extending `non_exported_macro_attrs` to include non-exported macros. That list was originally added in #62042 to handle stability attributes, so I suspect it was just an optimization since that was all that was needed. It was later extended to be included in SVH in #83901. #80641 also added a use to check for `invalid` attributes, which seems a little odd to me (it didn't validate non-exported macros, and seems highly specific).
Overall, there doesn't seem to be a clear story of when `unused_attributes` should be used versus an error like E0518. I considered alternatively using an "allow list" of built-in attributes that can be used on macro_rules (allow, warn, deny, forbid, cfg, cfg_attr, macro_export, deprecated, doc), but I feel like that could be a pain to maintain.
Some built-in attributes already present hard-errors when used with macro_rules. These are each hard-coded in various places:
- `derive`
- `test` and `bench`
- `proc_macro` and `proc_macro_derive`
- `inline`
- `global_allocator`
The primary motivation is that I sometimes see people use `#[macro_use]` in front of `macro_rules`, which indicates there is some confusion out there (evident that there was even a case of it in rustc).
bors [Sun, 16 May 2021 15:11:48 +0000 (15:11 +0000)]
Auto merge of #84549 - tmiasko:static-initializer, r=varkor
Reachable statics have reachable initializers
Static initializer can read other statics. Initializers are evaluated at
compile time, and so their content could become inlined into another
crate. Ensure that initializers of reachable statics are also reachable.
Previously, when an item incorrectly considered to be unreachable was
reached from another crate an attempt would be made to codegen it. The
attempt could fail with an ICE (in the case MIR wasn't available to do
so) in some circumstances the attempt could also succeed resulting in
a local codegen of non-local items, including static ones.
bors [Sun, 16 May 2021 12:30:07 +0000 (12:30 +0000)]
Auto merge of #85316 - eddyb:cg-ssa-on-demand-cleanuppad, r=nagisa
rustc_codegen_ssa: generate MSVC cleanup pads on demand, like GNU landing pads.
This unblocks #84993 in terms of codegen tests, as it brings the MSVC-style (`cleanup_pad`) EH (LLVM) block order in line with the GNU-style (`landing_pad`) EH (LLVM) block order, by having both of them be on-demand (instead of MSVC-style being eager and GNU-style lazy/on-demand).
It also unifies the two implementations a bit, similar to #84699, but in the opposite direction (as that attempt made both kinds of EH pads eagerly built).
~~Opening as draft because I haven't done enough Windows testing just yet, of both this PR, and of #84993 rebased on it.~~ (**EDIT**: seems to be working as expected)
bors [Sun, 16 May 2021 09:49:12 +0000 (09:49 +0000)]
Auto merge of #85332 - RalfJung:ptr-in-str, r=oli-obk
CTFE validation: handle pointers in str
I also finally learned how I can match *some* NOTEs in a ui test without matching all of them, and applied that to some const tests in the 2nd commit where I added NOTE because I did not know what I was doing. I can separate this into its own PR if you prefer.
bors [Sun, 16 May 2021 00:54:01 +0000 (00:54 +0000)]
Auto merge of #85259 - Smittyvb:thir-unsafeck-inline-asm, r=nikomatsakis
Check for inline assembly in THIR unsafeck
#83129 was merged recently and added a THIR unsafe checker. This adds a check for inline assembly. (and this is 2x simpler than the MIR version, which has to check for `asm` and `llvm_asm` in two separate spots!)
bors [Sat, 15 May 2021 22:27:09 +0000 (22:27 +0000)]
Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-se
Do not allocate or unwind after fork
### Objective scenarios
* Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures.
* Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs).
* In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740.
I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural.
#### Approach
* Provide a way for a program to, at runtime, switch to having panics abort. This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)).
* Make that change in the child spawned by `Command`.
* Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code.
* Test that this all works as expected (and in particular, that there aren't any heap allocations we missed)
* Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with.
* Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system.
* Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.)
### History
This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263, this MR has very substantial changes and additions.
Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.`
bors [Sat, 15 May 2021 19:58:59 +0000 (19:58 +0000)]
Auto merge of #84920 - Aaron1011:pretty-print-rental, r=petrochenkov
Remove some unncessary spaces from pretty-printed tokenstream output
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
See https://github.com/rust-lang/rust/issues/84428 for some background information about why we want to make this change. Note that this change would be desirable (but not particularly necessary) even if `rental` didn't exist, so we're not adding any crate-specific hacks into the compiler.
Aaron Hill [Sat, 1 May 2021 19:54:47 +0000 (15:54 -0400)]
Remove some unncessary spaces from pretty-printed tokenstream output
In addition to making the output look nicer for all crates, this also
aligns the pretty-printing output with what the `rental` crate expects.
This will allow us to eventually disable a backwards-compat hack in a
follow-up PR.
Guillaume Gomez [Sat, 15 May 2021 15:56:50 +0000 (17:56 +0200)]
Rollup merge of #85329 - RalfJung:version, r=Mark-Simulacrum
fix version_str comment
This version string is ultimately generated here
https://github.com/rust-lang/rust/blob/87423fbc6af5aae2b5f6d0a11f2a0c60c7c22e98/src/bootstrap/channel.rs#L72
and I don't think it includes the `rustc` prefix. That also matches its use here
https://github.com/rust-lang/rust/blob/ac923d94f86a6f7c881ecbedcd0a68d7986a35bd/compiler/rustc_driver/src/lib.rs#L758
Guillaume Gomez [Sat, 15 May 2021 15:56:49 +0000 (17:56 +0200)]
Rollup merge of #85324 - FabianWolff:issue-85255, r=varkor
Warn about unused `pub` fields in non-`pub` structs
This pull request fixes #85255. The current implementation of dead code analysis is too prudent because it marks all `pub` fields of structs as live, even though they cannot be accessed from outside of the current crate if the struct itself only has restricted or private visibility.
I have changed this behavior to take the containing struct's visibility into account when looking at field visibility and liveness. This also makes dead code warnings more consistent; consider the example given in #85255:
```rust
struct Foo {
a: i32,
pub b: i32,
}
fn main() {
let _ = Foo { a: 1, b: 2 };
let _ = Bar;
}
```
Current nightly already warns about `Bar::b()`, even though it is `pub` (but `Bar` is not). It should therefore also warn about `Foo::b`, which it does with the changes in this PR.
Guillaume Gomez [Sat, 15 May 2021 15:56:47 +0000 (17:56 +0200)]
Rollup merge of #84751 - Soveu:is_char_boundary_opt, r=Amanieu
str::is_char_boundary - slight optimization
Current `str::is_char_boundary` implementation emits slightly more instructions, because it includes an additional branch for `index == s.len()`
```rust
pub fn is_char_boundary(s: &str, index: usize) -> bool {
if index == 0 || index == s.len() {
return true;
}
match s.as_bytes().get(index) {
None => false,
Some(&b) => (b as i8) >= -0x40,
}
}
```
Just changing the place of `index == s.len()` merges it with `index < s.len()` from `s.as_bytes().get(index)`
```rust
pub fn is_char_boundary2(s: &str, index: usize) -> bool {
if index == 0 {
return true;
}
match s.as_bytes().get(index) {
// For some reason, LLVM likes this comparison here more
None => index == s.len(),
// This is bit magic equivalent to: b < 128 || b >= 192
Some(&b) => (b as i8) >= -0x40,
}
}
```
This one has better codegen on every platform, except powerpc
<details><summary>x86 codegen</summary>
<p>
```nasm
example::is_char_boundary:
mov al, 1
test rdx, rdx
je .LBB0_5
cmp rsi, rdx
je .LBB0_5
cmp rsi, rdx
jbe .LBB0_3
cmp byte ptr [rdi + rdx], -65
setg al
.LBB0_5:
ret
.LBB0_3:
xor eax, eax
ret
example::is_char_boundary2:
test rdx, rdx
je .LBB1_1
cmp rsi, rdx
jbe .LBB1_4
cmp byte ptr [rdi + rdx], -65
setg al
ret
.LBB1_1: ; technically this branch is the same as LBB1_4
mov al, 1
ret
.LBB1_4:
sete al
ret
```
</p>
</details>
bors [Sat, 15 May 2021 14:55:56 +0000 (14:55 +0000)]
Auto merge of #82208 - jyn514:rustfmt-subtree, r=Mark-Simulacrum
Convert rustfmt from a submodule to a subtree
r? `@calebcartwright` cc `@Manishearth` `@Mark-Simulacrum`
The motivation is that submodule updates cause rustfmt to not be available on nightly a lot; most recently it was unavailable for over 10 days, causing the beta release to be delayed. Additionally this is much less work on the part of the rustfmt maintainers to keep the rustfmt compiling, since now people making breaking changes will be responsible for fixing them.
I kept the rustfmt git history so it looks like there are thousands of commits. The important commits are https://github.com/rust-lang/rust/compare/851dee3af9404bf399c3c4ffefe5105edb3debad~..pull/82208/head. This adds about 10 MB of git history, which is not terribly much compared to the 702 MB that already exist.
- Add `src/tools/rustfmt` to `x.py check`
- Fix CRLF issues with rustfmt tests (see commit for details)
- Use `rustc_private` instead of crates.io dependencies
This was already switched upstream and would have landed in the next submodule bump anyway. This just updates Cargo.lock for rust-lang/rust.
- Add `yansi-term` to the list of allowed dependencies.
This is a false positive - rustc doesn't actually use it, only rustfmt, but because it's activated by the cargo feature of a dependency, tidy gets confused. It's fairly innocuous in any case, it's used for color printing.
This would have happened in the next submodule bump.
- Remove rustfmt from the list of toolstate tools.
- Give a hard error if testing or building rustfmt fails.
- Update log to 0.4.14
This avoids a warning about semicolons in macros; see the commit for details.
- Don't add tools to the sysroot when they finish building.
This is the only change that could be considered a regression - this avoids a "colliding StableCrateId" error due to a bug in resolve (https://github.com/rust-lang/rust/issues/56935). The regression is that this rebuilds dependencies more often than strictly necessary. See the commit for details.
Fixes https://github.com/rust-lang/rust/issues/85226 (permanently). Closes https://github.com/rust-lang/rust/issues/82385. Helps with https://github.com/rust-lang/rust/issues/70651. Helps with https://github.com/rust-lang/rust/issues/80639.
bors [Sat, 15 May 2021 12:41:28 +0000 (12:41 +0000)]
Auto merge of #85328 - GuillaumeGomez:rollup-exe9nbj, r=GuillaumeGomez
Rollup of 12 pull requests
Successful merges:
- #84461 (rustdoc: Remove unnecessary `StripItem` wrapper)
- #85067 (Minimize amount of fake `DefId`s used in rustdoc)
- #85207 (Fix typo in comment)
- #85215 (coverage bug fixes and some refactoring)
- #85221 (dbg macro: Discuss use in tests, and slightly clarify)
- #85246 (Miner code formatting)
- #85253 (swap function order for better read flow)
- #85256 (Fix display for "implementors" section)
- #85268 (Use my real name)
- #85278 (Improve match statements)
- #85289 (Fix toggle position on mobile)
- #85323 (Fix eslint errors)
Guillaume Gomez [Sat, 15 May 2021 11:29:52 +0000 (13:29 +0200)]
Rollup merge of #85253 - RafaelKr:patch-1, r=varkor
swap function order for better read flow
I was reading this error message for the first time.
I was a little bit confused when reading that part:
```
foo.bar(); // we can now use this method since i32 implements the Foo trait
```
At the time I was reading `// we can now use this method` I wasn't sure why. It only made sense when reading on. So swapping these parts results in a better read flow.
Guillaume Gomez [Sat, 15 May 2021 11:29:49 +0000 (13:29 +0200)]
Rollup merge of #85215 - richkadel:ice-fixes-minus-dead-blocks, r=tmandry
coverage bug fixes and some refactoring
This replaces the relevant commits (2 and 3) from PR #85082, and also corrects an error querying for coverageinfo.
1. `coverageinfo` query needs to use the same MIR as codegen
I ran into an error trying to fix dead block coverage and realized the
`coverageinfo` query is getting a different MIR compared to the
codegenned MIR, which can sometimes be a problem during mapgen.
I changed that query to use the `InstandeDef` (which includes the
generic parameter substitutions, prosibly specific to const params)
instead of the `DefId` (without unknown/default const substitutions).
2. Simplified body_span and filtered span code
Some code cleanup extracted from future (but unfinished) commit to fix
coverage in attr macro functions.
3. Spanview needs the relevant body_span used for coverage
The coverage body_span doesn't always match the function body_span.
Guillaume Gomez [Sat, 15 May 2021 11:29:47 +0000 (13:29 +0200)]
Rollup merge of #85067 - Stupremee:minimize-amount-of-fake-defids, r=jyn514,GuillaumeGomez
Minimize amount of fake `DefId`s used in rustdoc
Follow up from #84707, which minimizes the amount of fake defids to the smallest amount possible. Every `FakeDefId` that is now used in the rustdoc library must be preserved and can not be replaced with a normal `DefId`.
bors [Sat, 15 May 2021 10:00:39 +0000 (10:00 +0000)]
Auto merge of #84152 - sexxi-goose:insignificant_dtor, r=nikomatsakis
Insignificant destructors rfc 2229
- Adds new attribute `rustc_insignificant_dtor` to annotate the drop method.
- Adds a query to check if a type has a significant drop.
- Updates closure analysis to check for significant drops rather than just drop.
A type marked with the attribute `rustc_insignificant_dtor` is considered to not be significant. A drop is significant if it is implemented by the user or does anything that will have any observable behavior (other than freeing up memory).
bors [Sat, 15 May 2021 07:44:21 +0000 (07:44 +0000)]
Auto merge of #85311 - camelid:box-blanket-impl, r=jyn514
Box `Impl.blanket_impl` to reduce size
Blanket impls are probably not super common, and `Type` is a fairly
large type, so this should reduce `Impl`'s size by a lot: `Option<Type>`
is around 96 bytes, and `Option<Box<Type>>` is 8 bytes, so it's a big
difference!
bors [Sat, 15 May 2021 05:20:49 +0000 (05:20 +0000)]
Auto merge of #84997 - pietroalbini:ci-verify-channel, r=Mark-Simulacrum
Error out if a PR is sent to the wrong channel
It happened multiple times that a PR meant to go on beta ends up being opened (and occasionally merged) to master. This PR does two things:
* Moves the definition of the channel in `src/ci/channel` so it's easier for tools to read it. I was not sure whether to move it to `src/channel` (like `src/version`): ended up with `src/ci` as it's currently only used for CI, but I'm open to moving it to `src`. We'll need to update the release process after this.
* Adds a check on **non-bors** builds that errors out if the base branch is not the expected one for the currently defined channel. This will not cause problems for promotion PRs, as those PRs are meant to also update the channel name.
Joshua Nelson [Sun, 2 May 2021 20:56:25 +0000 (16:56 -0400)]
Update log to 0.4.14
This avoids the following warning:
```
warning: trailing semicolon in macro used in expression position
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.11/src/macros.rs:152:45
|
147 | / macro_rules! debug {
148 | | (target: $target:expr, $($arg:tt)+) => (
149 | | log!(target: $target, $crate::Level::Debug, $($arg)+);
150 | | );
151 | | ($($arg:tt)+) => (
152 | | log!($crate::Level::Debug, $($arg)+);
| | ^
153 | | )
154 | | }
| |_- in this expansion of `debug!`
|
::: src/tools/rustfmt/src/modules/visitor.rs:36:23
|
36 | Err(e) => debug!("{}", e),
| --------------- in this macro invocation
|
= note: requested on the command line with `-W semicolon-in-expressions-from-macros`
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
```
Joshua Nelson [Sun, 2 May 2021 18:27:57 +0000 (14:27 -0400)]
Don't copy tool dependencies to the sysroot
This fixes the following error:
```
error: found crates (`serde_derive` and `serde_derive`) with colliding StableCrateId values.
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/cargo_metadata-0.8.2/src/lib.rs:162:1
|
162 | extern crate serde_derive;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This is a bug in resolve (https://github.com/rust-lang/rust/issues/56935)
but it will be difficult to fix in the near future. This works around it
in the meantime by not copying serde_derive and other dependencies to
the sysroot when they're built for other tools. This rebuilds the
dependencies slightly more often than necessary, but avoids the crate
conflicts.
Joshua Nelson [Wed, 17 Feb 2021 03:37:17 +0000 (22:37 -0500)]
Update bootstrap for in-tree rustfmt
- Add rustfmt to `x.py check`
- Update Cargo.lock
- Remove rustfmt from the toolstate list
- Make rustfmt an in-tree tool
- Give an error on `x.py test rustfmt` if rustfmt fails to build or if tests fail
- Don't call `save_toolstate` when testing rustfmt
Noah Lev [Sat, 15 May 2021 00:36:58 +0000 (17:36 -0700)]
Box `Impl.blanket_impl` to reduce size
Blanket impls are probably not super common, and `Type` is a fairly
large type, so this should reduce `Impl`'s size by a lot: `Option<Type>`
is around 96 bytes, and `Option<Box<Type>>` is 8 bytes, so it's a big
difference!
projects / rust.git / log