| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Brought up during the discussion of #35118, the support for this is still
somewhat buggy and so stabilization likely wants to be considered independently
of the type itself.
|
|
|
|
|
|
Lambda expressions honor no struct literal restriction
This is a fix for #43412 if we decide that it is indeed a bug :)
closes #43412
|
|
|
|
feature error span on attribute for fn_must_use, SIMD/align reprs, macro reëxport
There were several feature-gated attributes for which the feature-not-available
error spans would point to the item annotated with the gated attribute, when it
would make more sense for the span to point to the attribute itself: if the
attribute is removed, the function/struct/_&c._ likely still makes sense and the
program will compile. (Note that we decline to make the analogous change for
the `main`, `start`, and `plugin_registrar` features, for in those cases it
makes sense for the span to implicate the entire function, of which there is
little hope of using without the gated attribute.)
|
|
There were several feature-gated attributes for which the
feature-not-available error spans would point to the item annotated with
the gated attribute, when it would make more sense for the span to point
to the attribute itself: if the attribute is removed, the
function/struct/&c. likely still makes sense and the program will
compile. (Note that we decline to make the analogous change for the
`main`, `start`, and `plugin_registrar` features, for in those cases it
makes sense for the span to implicate the entire function, of which
there is little hope of using without the gated attribute.)
|
|
|
|
|
|
feature-gate #[must_use] for functions as `fn_must_use`
@eddyb I [was](https://github.com/rust-lang/rust/pull/43728#issuecomment-320854120) [dithering](https://github.com/rust-lang/rust/pull/43728#issuecomment-320856407) on this, but [your comment](https://github.com/rust-lang/rust/issues/43302#issuecomment-321174989) makes it sound like we do want a feature gate for this? Please advise.
r? @eddyb
|
|
Fixes #41701.
|
|
The value of this field is meant to indicate whether or not the
crate is rustc's libtest itself - not whether or not it is a test
crate generally.
|
|
|
|
|
|
|
|
This continues to be in the matter of #43302.
|
|
Before `#[must_use]` for functions was implemented, a `#[must_use]` attribute
on a function was a no-op. To avoid a breaking change in this behavior, we add
an option for "this-and-such feature is experimental" feature-gate messages to
be a mere warning rather than a compilation-halting failure (so old code that
used to have a useless no-op `#[must_use]` attribute now warns rather than
breaking). When we're on stable, we add a help note to clarify that the feature
isn't "on."
This is in support of #43302.
|
|
The featureck.py that this comment referred to was removed in 9dd3c54a (March
2016).
|
|
We'll actually want a new "soft" warning-only gate to maintain
backwards-compatibility, but it's cleaner to start out with the established,
well-understood gate before implementing the alternative warn-only behavior in
a later commit.
This is in the matter of #43302.
|
|
|
|
|
|
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
|
|
|
|
Fix bad span for attributes
Closes #42641.
|
|
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`.
|
|
|
|
|
|
|
|
Fixes #43692.
|
|
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 typos & us spellings
Fixing some typos and non en-US spellings.
(Update of PR https://github.com/rust-lang/rust/pull/42812 )
|
|
|
|
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Include 'let' keyword to the span for ast::Local
Currently the span for `ast::Local` does not the include the `let` keyword. This PR fixes it.
|
|
Fix some typos
Follow up of #43794
If refined my script a little bit and found some more.
|
|
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::thread::local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
|
|
|
