| Age | Commit message (Collapse) | Author | Lines |
|
This matches the behaviour for finding tests in Rust files.
|
|
rustdoc: Rename `Vector` and `FixedVector` to `Slice` and `Array`
Also store the array length as a usize rather than a String.
This is just a minor refactor.
|
|
Support VS 2017
Fixes #38584
This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions.
I've only tested this with x86_64.
r? @alexcrichton
cc @vadimcn @retep998
|
|
Fixes #38584
|
|
Also store the array length as a usize rather than a String.
This is just a minor refactor.
|
|
Upgrade ProjectionTy's Name to a DefId
Part of #42171, in preparation for downgrading the contained `TraitRef` to
only its `substs`.
Some inline questions in the diff. Look for `FIXME(tschottdorf)`. These comments
should be addressed before merging.
|
|
Rather than (ab)using Debug for outputting the type in plain text use the
alternate format parameter which already does exactly that. This fixes
type parameters for example which would output raw HTML.
Also cleans up adding parens around references to trait objects.
|
|
Part of #42171, in preparation for downgrading the contained `TraitRef` to
only its `substs`.
|
|
|
|
|
|
Initial implementation of declarative macros 2.0
Implement declarative macros 2.0 (rust-lang/rfcs#1584) behind `#![feature(decl_macro)]`.
Differences from `macro_rules!` include:
- new syntax: `macro m(..) { .. }` instead of `macro_rules! m { (..) => { .. } }`
- declarative macros are items:
```rust
// crate A:
pub mod foo {
m!(); // use before definition; declaration order is irrelevant
pub macro m() {} // `pub`, `pub(super)`, etc. work
}
fn main() {
foo::m!(); // named like other items
{ use foo::m as n; n!(); } // imported like other items
}
pub use foo::m; // re-exported like other items
// crate B:
extern crate A; // no need for `#[macro_use]`
A::foo::m!(); A::m!();
```
- Racket-like hygiene for items, imports, methods, fields, type parameters, privacy, etc.
- Intuitively, names in a macro definition are resolved in the macro definition's scope, not the scope in which the macro is used.
- This [explaination](http://beautifulracket.com/explainer/hygiene.html) of hygiene for Racket applies here (except for the "Breaking Hygiene" section). I wrote a similar [explanation](https://github.com/jseyfried/rfcs/blob/hygiene/text/0000-hygiene.md) for Rust.
- Generally speaking, if `fn f() { <body> }` resolves, `pub macro m() { <body> } ... m!()` also resolves, even if `m!()` is in a separate crate.
- `::foo::bar` in a `macro` behaves like `$crate::foo::bar` in a `macro_rules!`, except it can access everything visible from the `macro` (thus more permissive).
- See [`src/test/{run-pass, compile-fail}/hygiene`](https://github.com/rust-lang/rust/pull/40847/commits/afe7d89858fd72b983e24727d6f4058293153c19) for examples. Small example:
```rust
mod foo {
fn f() { println!("hello world"); }
pub macro m() { f(); }
}
fn main() { foo::m!(); }
```
Limitations:
- This does not address planned changes to matchers (`expr`,`ty`, etc.), c.f. #26361.
- Lints (including stability and deprecation) and `unsafe` are not hygienic.
- adding hygiene here will be mostly or entirely backwards compatible
- Nested macro definitions (a `macro` inside another `macro`) don't always work correctly when invoked from external crates.
- pending improvements in how we encode macro definitions in crate metadata
- There is no way to "escape" hygiene without using a procedural macro.
r? @nrc
|
|
|
|
|
|
Set --extend-css stable
I think it's now time to set this option stable.
r? @rust-lang/docs
|
|
|
|
For renamed reexports the new name should be used.
|
|
Fixed resubmission of #40719.
|
|
rustdoc: Fix implementors list javascript
* Use a different loop variable, `i` was already taken. This caused
missing items in the implementors list.
* Use `.getAttribute('href')` rather than `.href` to get the relative
URL which is what it needs to actually fix the links.
More fallout from #41307.
r? @GuillaumeGomez
|
|
Give a nicer error for non-Unicode arguments to rustc and rustdoc
Previously, any non-Unicode argument would panic rustc:
```
$ rustc $'foo\x80bar'
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value:
"foo�bar"', /checkout/src/libcore/result.rs:859 note: Run with
`RUST_BACKTRACE=1` for a backtrace.
```
Now it gives a clean error:
```
$ rustc $'foo\x80bar'
error: Argument 1 is not valid Unicode: "foo�bar"
```
Maybe fixes #15890, although we still can't *compile* arbitrary file names.
|
|
* Use a different loop variable, `i` was already taken. This caused
missing items in the implementors list.
* Use `.getAttribute('href')` rather than `.href` to get the relative
URL which is what it needs to actually fix the links.
|
|
Previously, any non-Unicode argument would panic rustc:
```
$ rustc $'foo\x80bar'
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report:
https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value:
"foo�bar"', /checkout/src/libcore/result.rs:859 note: Run with
`RUST_BACKTRACE=1` for a backtrace.
```
Now it gives a clean error:
```
$ rustc $'foo\x80bar'
error: Argument 1 is not valid Unicode: "foo�bar"
```
Maybe fixes #15890, although we still can't *compile* arbitrary file names.
|
|
|
|
improve collapse toggle render (css)
The `[-]` toggle for functions in docs _seems_ too big. It's just an impression, but it's something I noticed long time ago (maybe I have bad taste). I never thought to fix it, but, today I think: "Ok, why not suggest it.". Feel free to close without explanation!
Preview changes below:
From this:
<img width="1003" alt="capture d ecran 2017-05-15 a 17 14 45" src="https://cloud.githubusercontent.com/assets/1575946/26064816/5c84de86-3992-11e7-976b-41c625cace0f.png">
To this:
<img width="996" alt="capture d ecran 2017-05-15 a 17 15 02" src="https://cloud.githubusercontent.com/assets/1575946/26064854/78325dac-3992-11e7-88f6-2c43db43421c.png">
|
|
rustdoc: Display `extern "C" fn` instead of `extern fn`
It was decided in rust-lang-nursery/fmt-rfcs#52 to be explicit about the ABI so rustdoc should follow suit.
|
|
|
|
Consequently, session creation can no longer initialize LLVM.
The few places that use the compiler without going through
rustc_driver/CompilerCalls thus need to be careful to manually
initialize LLVM (via rustc_trans!) immediately after session
creation.
This means librustc is not rebuilt when LLVM changes.
|
|
|
|
Move the code for loading metadata from rlibs and dylibs from
rustc_metadata into rustc_trans, and introduce a trait to avoid
introducing a direct dependency on rustc_trans.
This means rustc_metadata is no longer rebuilt when LLVM changes.
|
|
Fix anchor invalid redirection to search
Fixes #41933.
r? @rust-lang/docs
|
|
Add markdown-[before|after]-content options
cc @nical
r? @rust-lang/docs
|
|
|
|
Rollup of 15 pull requests
- Successful merges: #41820, #41860, #41876, #41896, #41912, #41916, #41918, #41921, #41923, #41934, #41935, #41940, #41942, #41943, #41951
- Failed merges:
|
|
rustc: Add a new `-Z force-unstable-if-unmarked` flag
This commit adds a new `-Z` flag to the compiler for use when bootstrapping the
compiler itself. We want to be able to use crates.io crates, but we also want
the usage of such crates to be as ergonomic as possible! To that end compiler
crates are a little tricky in that the crates.io crates are not annotated as
unstable, nor do they expect to pull in unstable dependencies.
To cover all these situations it's intended that the compiler will forever now
bootstrap with `-Z force-unstable-if-unmarked`. This flags serves a dual purpose
of forcing crates.io crates to themselves be unstable while also allowing them
to use other "unstable" crates.io crates. This should mean that adding a
dependency to compiler no longer requires upstream modification with
unstable/staged_api attributes for inclusion!
|
|
rustdoc: Break words in the location box of the sidebar.
This prevents long names from overflowing.
Before:

After:

|
|
|
|
This prevents long names from overflowing.
|
|
These are now no longer necessary with `-Z force-unstable-if-unmarked`
|
|
|
|
|
|
|
|
|
|
Allow # to appear in rustdoc code output.
"##" at the start of a trimmed rustdoc line is now cut to "#" and then
shown. If the user wanted to show "##", they can type "###".
I'm somewhat concerned about the potential implications for users, since this does make a potentially backwards-incompatible change. Previously, `##` had no special handling, and now we do change it. However, I'm not really sure what we can do here to improve this, and I can't think of any cases where `##` would likely be correct in a code block, though of course I could be wrong.
Fixes #41783.
|
|
"##" at the start of a trimmed rustdoc line is now cut to "#" and then
shown. If the user wanted to show "##", they can type "###".
|
|
Add option to display warnings in rustdoc
Part of #41574.
r? @alexcrichton
The output for this file:
```rust
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo() {}
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// ```
fn foo2() {}
/// ```
/// fn foo(x: u32) {}
///
/// foo(2);
/// let x = 1;
/// panic!();
/// ```
fn foo3() {}
fn main() {
}
```
is the following:
```
> ./build/x86_64-apple-darwin/stage1/bin/rustdoc -Z unstable-options --display-warnings --test test.rs
running 3 tests
test test.rs - foo (line 1) ... FAILED
test test.rs - foo3 (line 18) ... FAILED
test test.rs - foo2 (line 10) ... ok
successes:
---- test.rs - foo2 (line 10) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
successes:
test.rs - foo2 (line 10)
failures:
---- test.rs - foo (line 1) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
thread 'rustc' panicked at 'test executable failed:
thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.
', src/librustdoc/test.rs:317
note: Run with `RUST_BACKTRACE=1` for a backtrace.
---- test.rs - foo3 (line 18) stdout ----
warning: unused variable: `x`
--> <anon>:2:8
|
2 | fn foo(x: u32) {}
| ^
|
= note: #[warn(unused_variables)] on by default
warning: unused variable: `x`
--> <anon>:5:5
|
5 | let x = 1;
| ^
|
= note: #[warn(unused_variables)] on by default
thread 'rustc' panicked at 'test executable failed:
thread 'main' panicked at 'explicit panic', <anon>:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.
', src/librustdoc/test.rs:317
failures:
test.rs - foo (line 1)
test.rs - foo3 (line 18)
test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured
```
|
|
Remove jquery dependency
r? @rust-lang/docs
Fixes #39159.
|
|
|
|
|
|
|
|
Removal pass for anonymous parameters
Removes occurences of anonymous parameters from the
rustc codebase, as they are to be deprecated.
See issue #41686 and RFC 1685.
r? @frewsxcv
|
|
On demandify region mapping
This is an adaptation of @cramertj's PR. I am sort of tempted to keep simplifying it, but also tempted to land it so and we can refactor more in follow-up PRs. As is, it does the following things:
- makes the region-maps an on-demand query, per function `tcx.region_maps(def_id)`
- interns code extents instead of of having them be integers
- remove the "root region extent" and (to some extent) item extents; instead we use `Option<CodeExtent<'tcx>>` in a few places (no space inefficiency since `CodeExtent<'tcx>` is now a pointer).
I'm not entirely happy with the way I have it setup though. Here are some of the changes I was considering (I'm not sure if they would work out well):
1. Removing `item_extents` entirely -- they are rarely used now, because most of the relevant places now accept an `Option<Region<'tcx>>` or an `Option<CodeExtent<'tcx>>`, but I think still used in a few places.
2. Merging `RegionMaps` into the typeck tables, instead of having it be its own query.
3. Change `CodeExtent<'tcx>` to store the parent pointer. This would mean that fewer places in the code actually *need* a `RegionMaps` anyhow, since most of them just want to be able to walk "up the tree". On the other hand, you wouldn't be able to intern a `CodeExtent<'tcx>` for some random node-id, you'd need to look it up in the table (since there'd be more information).
Most of this code is semi-temporary -- I expect it to largely go away as we move to NLL -- so I'm also not *that* concerned with making it perfect.
r? @eddyb
|