| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Fixes the off-by-one span issue where closure argument spans were
pointing to the token after the argument.
|
|
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO.
This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way.
I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo.
r? @alexcrichton
|
|
|
|
|
|
Rollup of 16 pull requests
Successful merges:
- #53652 (define copy_within on slices)
- #54261 (Make `dyn` a keyword in the 2018 edition)
- #54280 (remove (more) CAS API from Atomic* types where not natively supported)
- #54323 (rustbuild: drop color handling)
- #54350 (Support specifying edition in doc test)
- #54370 (Improve handling of type bounds in `bit_set.rs`.)
- #54371 (add -Zui-testing to rustdoc)
- #54374 (Make 'proc_macro::MultiSpan' public.)
- #54402 (Use no_default_libraries for all NetBSD flavors)
- #54409 (Detect `for _ in in bar {}` typo)
- #54412 (add applicability to span_suggestion call)
- #54413 (Add UI test for deref recursion limit printing twice)
- #54415 (parser: Tweak function parameter parsing to avoid rollback on succesfull path)
- #54420 (Compress `Liveness` data some more.)
- #54422 (Simplify slice's first(_mut) and last(_mut) with get)
- #54446 (Unify christianpoveda's emails)
Failed merges:
- #54058 (Introduce the partition_dedup/by/by_key methods for slices)
r? @ghost
|
|
parser: Tweak function parameter parsing to avoid rollback on succesfull path
Since rollback is not perfect and may e.g. leave non-fatal errors after it, we need to make sure compilation fails if it happens.
So in particular case of `fn parse_arg_general` we need to parse the "good" `TYPE` first and only then rollback and recover erroneous `PAT: TYPE` if necessary.
Found when working on https://github.com/rust-lang/rfcs/pull/2544#issuecomment-423293222.
r? @ghost
|
|
Detect `for _ in in bar {}` typo
Fix #36611, #52964, without modifying the parsing of emplacement `in` to avoid further problems like #50832.
|
|
Make `dyn` a keyword in the 2018 edition
Proposed in https://github.com/rust-lang/rust/issues/44662#issuecomment-421596088.
|
|
editions.
|
|
|
|
|
|
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
|
|
|
|
test incremental ThinLTO.
|
|
r=nikomatsakis
Add feature to enable bind by move pattern guards
Implement #15287 as described on https://github.com/rust-lang/rust/issues/15287#issuecomment-404827419
|
|
Issue 54246
I added the option of providing a help message for deprecated features, that takes precedence over the default `help: remove this attribute` message, along with messages for the features that mention replacements in the reason for deprecation.
Fixes #54246.
|
|
Merge `bitvec.rs` and `indexed_set.rs`
Because it's not good to have two separate implementations. Also, I will combine the best parts of each to improve NLL memory usage on some benchmarks significantly.
|
|
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.
This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs --> bit_set.rs
- indexed_set.rs --> (removed)
- BitArray + IdxSet --> BitSet (merged, see below)
- BitVector --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix --> BitMatrix
- SparseBitMatrix --> SparseBitMatrix
The changes within the bitset types themselves are as follows.
```
OLD OLD NEW
BitArray<C> IdxSet<T> BitSet<T>
-------- ------ ------
grow - grow
new - (remove)
new_empty new_empty new_empty
new_filled new_filled new_filled
- to_hybrid to_hybrid
clear clear clear
set_up_to set_up_to set_up_to
clear_above - clear_above
count - count
contains(T) contains(&T) contains(T)
contains_all - superset
is_empty - is_empty
insert(T) add(&T) insert(T)
insert_all - insert_all()
remove(T) remove(&T) remove(T)
words words words
words_mut words_mut words_mut
- overwrite overwrite
merge union union
- subtract subtract
- intersect intersect
iter iter iter
```
In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
`insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
over `contains_all`, `domain_size` over `num_bits`).
Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
|
|
Temporarily prohibit proc macro attributes placed after derives
... and also proc macro attributes used together with `#[test]`/`#[bench]`.
Addresses item 6 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393.
The end goal is straightforward predictable left-to-right expansion order for attributes.
Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order.
I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal.
How to fix broken code (derives):
- Move macro attributes above derives. This won't change expansion order, they are expanded before derives anyway.
Using attribute macros on same items with `#[test]` and `#[bench]` is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives.
How to fix broken code (test/bench):
- Enable `#![feature(plugin)]` (don't ask why).
r? @ghost
|
|
|
|
|
|
|
|
Note it requires MIR-borrowck to be enabled to actually do anything.
Note also that it implicitly turns off our AST-based check for
mutation in guards.
|
|
(Not sure if it is correct although).
|
|
Also fix some formatting along the way.
|
|
|
|
Use Applicability::Unspecified for all of them instead.
|
|
... and also proc macro attributes used together with test/bench.
|
|
Suggest && and || instead of 'and' and 'or'
Resolves #54109.
Note: competing pull reqeust: #54179
r? @csmoe
|
|
|
|
Implement RFC 2302: tuple_struct_self_ctor
Tracking issue: https://github.com/rust-lang/rust/issues/51994
|
|
Rollup of 11 pull requests
Successful merges:
- #53371 (Do not emit E0277 on incorrect tuple destructured binding)
- #53829 (Add rustc SHA to released DWARF debuginfo)
- #53950 (Allow for opting out of ThinLTO and clean up LTO related cli flag handling.)
- #53976 (Replace unwrap calls in example by expect)
- #54070 (Add Error::description soft-deprecation to RELEASES)
- #54076 (miri loop detector hashing)
- #54119 (Add some unit tests for find_best_match_for_name)
- #54147 (Add a test that tries to modify static memory at compile-time)
- #54150 (Updated 1.29 release notes with --document-private-items flag)
- #54163 (Update stage 0 to latest beta)
- #54170 (COMPILER_TESTS.md has been moved)
|
|
Advised by @estebank.
|
|
r=nikomatsakis
Add some unit tests for find_best_match_for_name
There were only some UI tests that covered this function.
Since there's more diagnostic work going on, I think it makes
sense to have this unit tested.
|
|
Closes #54109.
|
|
|
|
|
|
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
|
|
resolve: Future proof resolutions for potentially built-in attributes
This is not full "pass all attributes through name resolution", but a more conservative solution.
If built-in attribute is ambiguous with any other macro in scope, then an error is reported.
What complications arise with the full solution - https://github.com/rust-lang/rust/pull/53913#issuecomment-418204136.
cc https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
cc https://github.com/rust-lang/rust/issues/52269
Closes https://github.com/rust-lang/rust/issues/53531
|
|
Co-authored-by: nikomatsakis
|
|
stabilize #[used]
closes #40289
RFC for stabilization: rust-lang/rfcs#2386
r? @Centril
Where should this be documented? Currently the documentation is in the unstable book
|
|
There were only some UI tests that covered this function.
Since there's more diagnostic work going on, I think it makes
sense to have this unit tested.
|
|
Don't compute padding of braces unless they are unmatched
Follow up to #53949. Attempt to fix # #54083.
r? @nikomatsakis
|
|
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
|
|
Feature gate non-builtin attributes in inner attribute position
Closes item 3 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393
|
|
|
|
|