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.
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
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.
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#13951Fixes#23008Fixes#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.
