| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
|
|
Helps prevent mixed content warnings if accessing docs over HTTPS.
Closes #25459
|
|
Permit token trees, identifiers, and blocks to be following by sequences.
Fixes #25436.
r? @pnkfelix
|
|
Closes #25468.
|
|
Closes #25468.
|
|
Closes #24986.
|
|
Helps prevent mixed content warnings if accessing docs over HTTPS.
Closes #25459
|
|
sequences.
Fixes #25436.
|
|
Fixes #25182, parser didn't account for \r\n in regular comments, only doc-comments.
|
|
|
|
|
|
|
