Export attributes in save-analysis data
Since this is my first pull-request to rust, I would like to get some feedback about obvious errors in this implementation.
I would like to change the save-analysis data to include arbitrary attribute data.
A use-case I have in mind for this is identifying functions with `#[test]` annotations such that tools like rls can offer a test-runner feature. I described my idea here [rls#173](https://github.com/rust-lang-nursery/rls/issues/173).
My changes contain:
1. track a vector of attributes in the various `*Data` types in `data.rs` and `external_data.rs`
2. implement lowering for `Attribute` and `MetaItem`
3. adjust `JsonDumper` to print the attributes
In the lowering of `Attribute` I remove the distinction between `MetaItem` and `NestedMetaItem`. I did this because this distinction is somewhat confusing. For example, `NestedMetaItemKind::Literal` has two identical spans, because both `NestedMetaItem` and `Lit` are defined as `Spanned<_>`.
My model is strictly more general, as it allows an `LitKind` instead of a `Symbol` for `MetaItem` and `Symbol`s are converted into a cooked string. As a consumer of the save-analysis data this shouldn't affect you much.
Example json output of `#[test]` annotation:
```
"attributes": [
{
"value": {
"name": {
"variant": "Str",
"fields": [
"test",
"Cooked"
]
},
"kind": "Literal",
"span": {
"file_name": "test.rs",
"byte_start": 2,
"byte_end": 6,
"line_start": 1,
"line_end": 1,
"column_start": 3,
"column_end": 7
}
},
"span": {
"file_name": "test.rs",
"byte_start": 0,
"byte_end": 7,
"line_start": 1,
"line_end": 1,
"column_start": 1,
"column_end": 8
}
}
]
```
When declaring nested unsafe blocks (`unsafe {unsafe {}}`) that trigger
the "unnecessary `unsafe` block" error, point out the enclosing `unsafe
block` or `unsafe fn` that makes it unnecessary.
rustbuild: Use copies instead of hard links
The original motivation for hard links was to speed up the various stages of
rustbuild, but in the end this is causing problems on Windows (#39504).
This commit tweaks the build system to use copies instead of hard links
unconditionally to ensure that the files accessed by Windows are always
disjoint.
Locally this added .3s to a noop build, so it shouldn't be too much of a
regression hopefully!
Closes#39504
travis: Split the linux-tested-targets builder
Travis only gives us 30GB disk space and we don't currently have an option to
increase that. Each musl target generates "hello world" binaries of about 3.5MB
in size, and we're testing two targets in the same image. We have around 3k
run-pass tests and 2 musl targets which works out to around 20GB. That's
dangerously close to the limit and is causing PRs to bounce.
This PR splits up the builder in two, one for x86_64 musl and the other for
i686. Hopefully that'll keep us under the disk limit.
Closes#40359
Travis only gives us 30GB disk space and we don't currently have an option to
increase that. Each musl target generates "hello world" binaries of about 3.5MB
in size, and we're testing two targets in the same image. We have around 3k
run-pass tests and 2 musl targets which works out to around 20GB. That's
dangerously close to the limit and is causing PRs to bounce.
This PR splits up the builder in two, one for x86_64 musl and the other for
i686. Hopefully that'll keep us under the disk limit.
Closes#40359
This commit is a random stab in the dark to fix the spurious failures on #39518.
The leading theory of the spurious failures on Windows is that the compiler is
loading a path in the `deps` folder, passing it to `link.exe`, and then this is
racing with Cargo itself updating those paths.
This race, however, has a few unique properties:
* It's isolated to just libstd. Most crates are never passed to the linker and
simultaneously being worked on by Cargo. Cargo's typical execution of the
dependency graph never hits this problem.
* The crates are already all located in the sysroot in addition to the `deps`
folder. This means that the compiler actually has two candidates of crates to
load, and it's just arbitrarily rejecting one.
Together this means that we shouldn't need to fix this problem "in the large"
and we can instead just fix it in this isolated situation (hopefully). To solve
this the compiler's been updated to prefer crates from the sysroot to leave
Cargo's structure to itself.
We'll see if this actually allows the PR to land...
The original motivation for hard links was to speed up the various stages of
rustbuild, but in the end this is causing problems on Windows (#39504).
This commit tweaks the build system to use copies instead of hard links
unconditionally to ensure that the files accessed by Windows are always
disjoint.
Locally this added .3s to a noop build, so it shouldn't be too much of a
regression hopefully!
rustbuild: Assert directory creation succeeds
I've been seeing failures on the bots when building jemalloc and my assumption
is that it's because cwd isn't created. That may be possible if this
`create_dir_all` call change in this commit fails, in which case we ignore the
error.
This commit updates the location to call `create_dir_racy` which handles
concurrent invocations, as multiple build scripts may be trying to create the
`native` dir.
Update link to COMPILER_TESTS.md in CONTRIBUTING.md
Link to compiler test documentation was broken after the file was moved by #40086.
This updates the link to the new location of the file.
Added remove_from to vec.rs (#38143)
Turns out that if you push to someone's PR branch and cause the PR to close, you lose delegation 😞.
@madseagames I'm really sorry about that 😭
clarify docs for Args and ArgsOs
The args() and args_os() docs include a line about how the first element
is usually the program name. Include that line in the struct docs too.
Add compile-fail tests for remaining items in whitelist and remove it
Add compile-fail tests for `cfg_target_thread_local` and `unwind_attributes`, and remove the whitelist.
Let me know if I should clean up the tests (or if I've done anything else wrong, this is my first contribution to rust).
cc/ @est31
Fix personality_fn within the compiler_builtins
compiler_builtins may not have any unwinding within it to link correctly. This is notoriously
finicky, and this small piece of change removes yet another case where personality function
happens to get introduced.
Side note: I do remember solving the exact same thing before. I wonder why it has reappered...
@cuviper, could you please try building beta with this patch applied? It should apply cleanly. If it works, I’ll nominate to land this into beta.
Fixes(?) https://github.com/rust-lang/rust/issues/40251
Reduce size overhead of adaptative hashmap
Exposes a boolean flag in RawTable and use it instead of a bool field in HashMap.
Taking a bit from capacity or length would make overflow handling tricky.
Fixes: #40042
Issue #39688 - Help people find String::as_bytes() for UTF-8
Added in links for the inverse functions so people will know that as_bytes() is the inverse of from_utf8() and vice versa.
?r @steveklabnik
I've been seeing failures on the bots when building jemalloc and my assumption
is that it's because cwd isn't created. That may be possible if this
`create_dir_all` call change in this commit fails, in which case we ignore the
error.
This commit updates the location to call `create_dir_racy` which handles
concurrent invocations, as multiple build scripts may be trying to create the
`native` dir.
Makes the sidebar a light grey and highlights the currently viewed item
in the sidebar more prominently.
All visual design credit goes to @johnwhelchel (#37856)
