Point out missing if conditional
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix#13483.
syntax: Relax path grammar
TLDR: Accept the disambiguator `::` in "type" paths (`Type::<Args>`), accept the disambiguator `::` before parenthesized generic arguments (`Fn::(Args)`).
The "turbofish" disambiguator `::<>` in expression paths is a necessary evil required for path parsing to be both simple and to give reasonable results.
Since paths in expressions usually refer to values (but not necessarily, e.g. `Struct::<u8> { field: 0 }` is disambiguated, but refers to a type), people often consider `::<>` to be inherent to *values*, and not *expressions* and want to write disambiguated paths for values even in contexts where disambiguation is not strictly necessary, for example when a path is passed to a macro `m!(Vec::<i32>::new)`.
The problem is that currently, if the disambiguator is not *required*, then it's *prohibited*. This results in confusion - see https://github.com/rust-lang/rust/issues/41740, https://internals.rust-lang.org/t/macro-path-uses-novel-syntax/5561.
This PR makes the disambiguator *optional* instead of prohibited in contexts where it's not strictly required, so people can pass paths to macros in whatever form they consider natural (e.g. disambiguated form for value paths).
This PR also accepts the disambiguator in paths with parenthesized arguments (`Fn::(Args)`) for consistency and to simplify testing of stuff like https://github.com/rust-lang/rust/pull/41856#issuecomment-301219194.
Closes https://github.com/rust-lang/rust/issues/41740
cc @rust-lang/lang
r? @nikomatsakis
Eat open paren when parsing list in libsyntax/parse/attr.rs
This PR adds a small refactoring:
```diff
pub fn parse_meta_item_kind(&mut self) -> PResult<'a, ast::MetaItemKind> {
Ok(if self.eat(&token::Eq) {
ast::MetaItemKind::NameValue(self.parse_unsuffixed_lit()?)
- } else if self.token == token::OpenDelim(token::Paren) {
+ } else if self.eat(&token::OpenDelim(token::Paren)) {
ast::MetaItemKind::List(self.parse_meta_seq()?)
} else {
- self.eat(&token::OpenDelim(token::Paren));
ast::MetaItemKind::Word
})
}
```
in `parse_meta_item_kind()`, the parser calls `self.eat(&token::OpenDelim(token::Paren));` before returning `ast::MetaItemKind::Word` just to add `(` to expected token. It seems more natural to eat the paren when parsing `ast::MetaItemKind::List`.
On a case where an else conditional is missing, point this out
instead of the token immediately after the (incorrect) else block:
```
error: missing condition for `if` statemementt push fork -f
--> $DIR/issue-13483.rs:16:5
|
13 | } else if {
| ^ expected if condition here
```
instead of
```
error: expected `{`, found `else`
--> ../../src/test/ui/issue-13483.rs:14:7
|
14 | } else {
| ^^^^
```
Fix include! in doc tests
By making the path relative to the current file.
Fixes#43153
[breaking-change] - if you use `include!` inside a doc test, you'll need to change the path to be relative to the current file rather than relative to the working directory.
Expose all OS-specific modules in libstd doc.
1. Uses the special `--cfg dox` configuration passed by rustbuild when running `rustdoc`. Changes the `#[cfg(platform)]` into `#[cfg(any(dox, platform))]` so that platform-specific API are visible to rustdoc.
2. Since platform-specific implementations often won't compile correctly on other platforms, `rustdoc` is changed to apply `everybody_loops` to the functions during documentation and doc-test harness.
3. Since platform-specific code are documented on all platforms now, it could confuse users who found a useful API but is non-portable. Also, their examples will be doc-tested, so must be excluded when not testing on the native platform. An undocumented attribute `#[doc(cfg(...))]` is introduced to serve the above purposed.
Fixes#24658 (Does _not_ fully implement #1998).
Check #[thread_local] statics correctly in the compiler.
Fixes#43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes#17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std:🧵:local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
Reexport all SyntaxExtension variants
This was previously done very inconsistently and made matches look weird since some variants had the `SyntaxExtension::` prefix while others didn't.
Hint correct extern constant syntax
Error message for `extern "C" { const …}` is terse, and the right syntax is hard to guess given unfortunate difference between meaning of `static` in C and Rust.
I've added a hint for the right syntax.
Fixed mutable vars being marked used when they weren't
#### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue.
Fixes#43526, Fixes#30280, Fixes#25049
### Issue
Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings
```
fn do_thing<T>(mut arg : &mut T) {
... // don't touch arg - just deref it to access the T
}
```
### Fix
Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables.
#### Why not on things other than local variables?
* Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted.
* If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
This attribute has two effects:
1. Items with this attribute and their children will have the "This is
supported on **** only" message attached in the documentation.
2. The items' doc tests will be skipped if the configuration does not
match.
Avoid calling the column!() macro in panic
Closes#43057
This "fix" adds a new macro called `__rust_unstable_column` and to use it instead of the `column` macro inside panic. The new macro can be shadowed as well as `column` can, but its very likely that there is no code that does this in practice.
There is no real way to make "unstable" macros that are usable by stable macros, so we do the next best thing and prefix the macro with `__rust_unstable` to make sure people recognize it is unstable.
r? @alexcrichton
It's more pleasing to use the inner-attribute syntax (`#!` rather than
`#`) in the error message, as that is how `feature` attributes in
particular will be declared (as they apply to the entire crate).
Update the list of confusable characters
Also reorder and space the list to make it clearer for futures updates
and to come closer to the original list.
This was tedious but somewhat rewarding!
Thanks @est31 for the instructions.
Fixes#43629.
r? @est31
After repatriating error explanations to the global registry, some lurking
doctest failures surfaced and needed to be chased down. Sadly, a few doctests
needed to be ignored due to a not-yet-understood regression in the doctest
`compile_fail` functionality (filed #43707).
