To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
This is in the matter of issue #33394.
In 1a374b8, (pr #33046) fixed the error reporting of a specific
case, but the change that was introduced did not make sure that
`record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes
that were committed in 1a374b8.
This commit fixes issue #33293.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
print enum variant fields in docs
Right now we are repeating enum variants at the top, because the fields aren't shown with the actual docs. It's very annoying to have to scroll up and down to have both docs and field info. For struct variants we already list the fields.
enum docs look like this after this PR:
![screenshot from 2016-05-25 14-02-42](https://cloud.githubusercontent.com/assets/332036/15539231/84b018cc-2281-11e6-9666-1063655931f4.png)
There are degenerate cases for enum tuple variants with lots of fields:
![screenshot from 2016-05-25 14-01-00](https://cloud.githubusercontent.com/assets/332036/15539260/91e537ca-2281-11e6-8bf1-a3d6b2e78f65.png)
I was thinking that we could move the docs below the variant (slightly indented) or list the variant fields vertically instead of horizontally
r? @steveklabnik
Added examples/docs to split in str.rs
Added documentation clarifying the behavior of split when used with the empty string and contiguous separators. Addresses issue [33882](https://github.com/rust-lang/rust/issues/33882). This is my first time contributing to rust, so forgive me if I'm skipping any of the contribution steps.
Fixes#33882
Separate bindings from other patterns in HIR
Now when name resolution is done on AST, we can avoid dumping everything that looks like an identifier into `PatKind::Ident` in HIR.
`hir::PatKind::Ident` is removed, fresh bindings are now called `hir::PatKind::Binding`, everything else goes to `hir::PatKind::Path`.
I intend to do something with `PatKind::Path`/`PatKind::QPath` as well using resolution results, but it requires some audit and maybe some deeper refactoring of relevant resolution/type checking code to do it properly.
I'm submitting this part of the patch earlier to notify interested parties that I'm working on this.
cc @jseyfried
r? @eddyb
antlr grammar verification script now compiles under latest nightly
This is kind of a moving target, since none of libsyntax is stable, but at least this compiles for the time being.
save-analysis: be a bit more defensive with field sub-expressions
Prevents an ice with `(...).f` since the sub-expression is in the AST but not the HIR.
We could actually do better in this specific case, but it doesn't seem worth it.
Prevent overflows by increasing ring buffer size
Please note that this change is just done to prevent
issues as currently seen by syntex_syntax in future.
See https://github.com/serde-rs/syntex/pull/47 for details.
As shown in https://github.com/serde-rs/syntex/issues/33,
complex code can easily overflow the ring-buffer and
cause an assertion error.
test: Use `set sysroot` for more NDK compatibility
Recent versions of the Android NDK no longer ship debuggers like
`arm-linux-androideabi-gdb`, but instead one prebuilt binary `gdb`. We can
symlink this into place at least to get our detection still working, but it now
needs to be told what the sysroot is so it can correctly do... something. Long
story short, tests didn't pass with this change and after this change they pass.
mk: Fix bootstrapping cross-hosts on beta
The beta builds are currently failing, unfortunately, due to what is presumably
some odd behavior with our makefiles. The wrong bootstrap key is being used to
generate the stage1 cross-compiled libraries, which fails the build.
Interestingly enough if the targets are directly specified as part of the build
then it works just fine! Just a bare `make` fails...
Instead of trying to understand what's happening in the makefiles instead just
tweak how we configure the bootstrap key in a way that's more likely to work.
rustbuild: Add support for --enable-local-rust
This commit adds support for the `--enable-local-rust` `./configure` switch
which uses the locally installed `rustc` to bootstrap the compiler.