| Age | Commit message (Collapse) | Author | Lines |
|---|
|
There are multiple issues with them as designed and implemented.
cc #27364
Conflicts:
src/libsyntax/feature_gate.rs
src/test/auxiliary/xcrate_associated_type_defaults.rs
|
|
|
|
As per #26009 this PR implements a new collation system for extended-error metadata. I've tried to keep it as simple as possible for now, so there's no uniqueness checking and minimal modularity.
Although using a lint was discussed in #26009 I decided against this because it would require converting the AST output from the plugin back into an internal data-structure. Emitting the metadata from within the plugin prevents this double-handling. We also didn't identify this as the source of the failures last time, although something untoward was definitely happening... With that in mind I would like as much feedback as possible on this before it's merged, I don't want to break the bots again!
I've successfully built for my host architecture and I'm building an ARM cross-compiler now to test my assumptions about the various `CFG` variables. Despite the confusing name of `CFG_COMPILER_HOST_TRIPLE` it is actually the compile time target triple, as explained in `mk/target.mk`.
```
# This is the compile-time target-triple for the compiler. For the compiler at
# runtime, this should be considered the host-triple. More explanation for why
# this exists can be found on issue #2400
export CFG_COMPILER_HOST_TRIPLE
```
CC @pnkfelix @brson @nrc @alexcrichton
Closes #25705, closes #26009.
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
|
|
This commit shards the all-encompassing `core`, `std_misc`, `collections`, and `alloc` features into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized.
A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.
|
|
r? @nrc, because breakage was caused by https://github.com/rust-lang/rust/pull/25318
|
|
|
|
This commit also deprecates the `as_string` and `as_slice` free functions in the
`string` and `vec` modules.
|
|
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
|
|
PR for #26128.
Improves codegen in deriving by utilizing the discriminant_value intrinsic.
I have a more detailed comment on the changes in a comment on the issue [here](https://github.com/rust-lang/rust/issues/26128#issuecomment-111509863)
### Old
```
running 7 tests
test large_c_like ... bench: 2,694,129 ns/iter (+/- 5,170)
test large_c_like_ord ... bench: 2,723,521 ns/iter (+/- 9,098)
test test1_partial_eq ... bench: 2,439,317 ns/iter (+/- 2,135)
test test1_partial_ord ... bench: 2,499,114 ns/iter (+/- 55,766)
test test2_partial_eq ... bench: 3,562,815 ns/iter (+/- 45,590)
test test2_partial_ord ... bench: 3,398,306 ns/iter (+/- 22,180)
test test_match_success ... bench: 1,509,267 ns/iter (+/- 1,982)
```
### New
```
running 7 tests
test large_c_like ... bench: 286,509 ns/iter (+/- 474)
test large_c_like_ord ... bench: 286,666 ns/iter (+/- 8,756)
test test1_partial_eq ... bench: 286,584 ns/iter (+/- 2,789)
test test1_partial_ord ... bench: 286,470 ns/iter (+/- 516)
test test2_partial_eq ... bench: 2,228,997 ns/iter (+/- 34,191)
test test2_partial_ord ... bench: 1,731,699 ns/iter (+/- 21,756)
test test_match_success ... bench: 1,509,630 ns/iter (+[- 3,765)
```
[Benchmark](https://gist.github.com/Marwes/7c0b3468d0cae972a2b4)
|
|
|
|
These used to return wrong results in case they were expanded inside compiler’s
iternal syntax sugar (closures, if-let) expansions
Fixes #26322
|
|
Replaced it with a comment mentioning the rationale for checking the discriminants first.
|
|
|
|
The new code generated for deriving on enums looks something like this:
```rust
let __self0_vi = unsafe {
std::intrinsics::discriminant_value(&self) } as i32;
let __self1_vi = unsafe {
std::intrinsics::discriminant_value(&__arg1) } as i32;
let __self2_vi = unsafe {
std::intrinsics::discriminant_value(&__arg2) } as i32;
///
if __self0_vi == __self1_vi && __self0_vi == __self2_vi && ... {
match (...) {
(Variant1, Variant1, ...) => Body1
(Variant2, Variant2, ...) => Body2,
...
_ => ::core::intrinsics::unreachable()
}
}
else {
... // catch-all remainder can inspect above variant index values.
}
```
This helps massively for C-like enums since they will be compiled as a
single comparison giving observed speedups of up to 8x. For more complex
enums the speedup is more difficult to measure but it should not be
slower to generate code this way regardless.
|
|
Pull request for #26188.
|
|
|
|
|
|
- Successful merges: #26142, #26143, #26145, #26146, #26164, #26174
- Failed merges:
|
|
|
|
Using two terms for one thing is confusing, these are called 'raw pointers' today.
|
|
Issue: #26083
Re-submitting https://github.com/rust-lang/rust/pull/26084
r? @nrc
|
|
r? @eddyb
|
|
|
|
|
|
Issue: https://github.com/rust-lang/rust/issues/25969
Compare the span on the stable branch (correct) with the span on the nightly branch (incorrect) for the following example: http://is.gd/lTAo9c. This pull request fixes the regression.
@Manishearth has been kind enough to pitch some ideas for a regression test, mainly revolving around testing the span in compile-fail test, but this has proven unsuccessful. Other suggestions/ ideas would be much appreciated!
|
|
|
|
This was always a weird feature, and isn't being used in the compiler.
Static assertions should be done better than this.
This implements RFC #1096.
Fixes #13951
Fixes #23008
Fixes #6676
This is behind a feature gate, but that's still a
[breaking-change]
|
|
|
|
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes #25763.
|
|
Needed to support:
```rust
match X {
pattern if Y ...
}
for pattern in Y {}
```
IMO, this shouldn't require an RFC because it can't interfere with any future language changes (because `pattern if` and `pattern in` are already legal in rust) and can't cause any ambiguity.
|
|
|
|
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Fixes #25763.
|
|
by 90%.
|
|
This is a port of @eddyb's `const-fn` branch. I rebased it, tweaked a few things, and added tests as well as a feature gate. The set of tests is still pretty rudimentary, I'd appreciate suggestions on new tests to write. Also, a double-check that the feature-gate covers all necessary cases.
One question: currently, the feature-gate allows the *use* of const functions from stable code, just not the definition. This seems to fit our usual strategy, and implies that we might (perhaps) allow some constant functions in libstd someday, even before stabilizing const-fn, if we were willing to commit to the existence of const fns but found some details of their impl unsatisfactory.
r? @pnkfelix
|
|
This lets plugin authors opt attributes out of the `custom_attribute`
and `unused_attribute` checks.
cc @thepowersgang
|
|
fixes #25683
I have a very nonscientific measurement of the data via valgrind/massif [here](https://gist.github.com/Manishearth/4c47f15f6835cb3957c4)
I measured the memory usage for both --pretty=expanded and -Z no-trans
It *seems* like there's a 20-25MB decrease during expansion on stage2 librustc; but I'm not quite sure.
r? @eddyb
(have not yet run tests, but it compiles fine, might want to wait before giving r+)
cc @nrc @huon
|
|
Needed to support:
match X {
pattern if Y ...
}
for pattern in Y {}
|
|
|
|
This is meant to be a temporary measure to get the builds to be
reliable again; see also Issue #25705.
|
|
|
|
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
|
|
|
|
|
|
Closes #25394
|
|
Closes #25394
|
|
The attribute was removed by #16499.
|
