| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit polishes off this new function to compile on newer rustc as well as
update and add a suite of test cases to work with this new check for lints.
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #52286 (Deny bare trait objects in src/librustc_errors)
- #52306 (Reduce the number of clone()s needed in obligation_forest)
- #52338 (update miri)
- #52385 (Pass edition flags to compiler from rustdoc as expected)
- #52392 (AsRef doc wording tweaks)
- #52430 (update nomicon)
- #52434 (Enable incremental independent of stage)
- #52435 (Calculate the exact capacity for 2 HashMaps)
- #52446 (Block beta if clippy breaks.)
r? @ghost
|
|
html5ever in the rustc-perf repository is memory-intensive
Part of #52028. Rebased atop of #51987.
r? @nikomatsakis
|
|
r=QuietMisdreavus
Pass edition flags to compiler from rustdoc as expected
Fixes #52357.
|
|
Block beta if clippy breaks.
Also, don't fail master pull request when an unrelated tool is not test-pass.
|
|
Enable incremental independent of stage
Previously we'd only do so for stage 0 but with keep-stage
improvements it seems likely that we'll see more developers working in
the stage 1, so we should allow enabling incremental for them.
|
|
update miri
|
|
Calculate the exact capacity for 2 HashMaps
|
|
Reduce the number of clone()s needed in obligation_forest
Some can be avoided by using `remove_entry` instead of `remove`.
|
|
Deny bare trait objects in src/librustc_errors
Enforce `#![deny(bare_trait_objects)]` in `src/librustc_errors`.
|
|
update nomicon
Will this trigger a website update automatically or is that a separate step?
|
|
|
|
|
|
|
|
`BitSlice` fixes
`propagate_bits_into_entry_set_for` and `BitSlice::bitwise` are hot for some benchmarks under NLL. I tried and failed to speed them up. (Increasing the size of `bit_slice::Word` from `usize` to `u128` caused a slowdown, even though decreasing the size of `bitvec::Word` from `u128` to `u64` also caused a slowdown. Weird.)
Anyway, along the way I fixed up several problems in and around the `BitSlice` code.
r? @nikomatsakis
|
|
Move some `compile-fail` tests to `ui`
Re: #44844.
|
|
Also modify `SparseBitMatrix` so that it does not require knowing the
dimensions in advance, but instead grows on demand.
|
|
|
|
Deny bare trait objects in librustc_driver
Enforce `#![deny(bare_trait_objects)]` in `src/librustc_driver`.
|
|
Update clippy
Fixes test failures caused by https://github.com/rust-lang/rust/pull/52081
|
|
Fixes test failures caused by https://github.com/rust-lang/rust/pull/52081
|
|
Don't fail master pull request when an unrelated tool is not test-pass.
|
|
rustc: Stabilize the `proc_macro` feature
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
|
|
AsRef doc wording tweaks
|
|
|
|
Previously we'd only do so for stage 0 but with keep-stage
improvements it seems likely that we'll see more developers working in
the stage 1, so we should allow enabling incremental for them.
Ideally, the check we probably want is to only enable incremental for
the last compiler build scheduled, but there's no good way to do so
today. Just enabling incremental in all stages should be sufficient;
we may be doing extra work that's needles -- compiling incrementally
something that will never be recompiled in-place -- but that should be
sufficiently unlikely (i.e., users either don't care or won't be
compiling the compiler twice).
|
|
Deny bare trait objects in librustc_driver
Enforce `#![deny(bare_trait_objects)]` in `src/librustc_driver`.
|
|
This commit stabilizes some of the `proc_macro` language feature as well as a
number of APIs in the `proc_macro` crate as [previously discussed][1]. This
means that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or `macro_rules!`-like bang-style
invocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the `use_extern_macros` feature. Currently you can define a
procedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
* The `proc_macro` language and library features are now stable.
* Other APIs not stabilized in the `proc_macro` crate are now named under a
different feature, such as `proc_macro_diagnostic` or `proc_macro_span`.
* A few checks in resolution for `proc_macro` being enabled have switched over
to `use_extern_macros` being enabled. This means that code using
`#![feature(proc_macro)]` today will likely need to move to
`#![feature(use_extern_macros)]`.
It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of `use_extern_macros` just for procedural macros to
make this feature 100% usable on stable.
[1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
|
|
|
|
Rename spanned HIR node enums from Foo_ to FooKind
Closes https://github.com/rust-lang/rust/issues/51968
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert #52266
Reverts #52266 until the performance issues with that PR are ironed out.
|
|
structured suggestion for renamed-and-removed-lints
r? @estebank
|
|
This reverts commit 9df56ca0eea1a8f5af945df25ce23e276b1d48a7.
|
|
This reverts commit 8dc7ddb9763f28b83de7bf3b3025f8042ea9e830.
|
|
This reverts commit 2c5cd9ce53d2d25041db0cb02b40ba460ffa8908.
|
|
This reverts commit f6894ebe664d111259a91a2b5fcc1236ca413436.
|
|
This reverts commit 94b32adb71a75a3f5b53a39c52c62c2ce1a7cc56.
|
|
This reverts commit dd3f445ed264ffc09ea42bd8d89853242e3a26f4.
|
