| Age | Commit message (Collapse) | Author | Lines |
|
Speed up `nearest_common_ancestor`.
`nearest_common_ancestor` can be made faster.
Here are all the benchmarks where one of the measurements improved by at least 1%.
```
clap-rs-check
avg: -4.5% min: -8.8% max: -0.3%
clap-rs
avg: -2.6% min: -4.5% max: 0.5%
script-servo
avg: -1.7% min: -3.6% max: 0.0%
regression-31157
avg: -1.5% min: -2.6% max: -0.4%
hyper
avg: -1.2% min: -2.5% max: -0.0%
piston-image
avg: -1.6% min: -2.5% max: 0.1%
regex
avg: -1.2% min: -2.2% max: 0.0%
issue-46449
avg: -1.8% min: -2.1% max: -0.7%
crates.io
avg: -1.2% min: -2.1% max: 0.0%
hyper-check
avg: -1.0% min: -2.1% max: -0.1%
clap-rs-opt
avg: -1.4% min: -2.0% max: -0.3%
piston-image-check
avg: -1.2% min: -1.9% max: -0.1%
regex-check
avg: -0.5% min: -1.8% max: -0.1%
syn
avg: -1.1% min: -1.7% max: -0.1%
tokio-webpush-simple-check
avg: -1.1% min: -1.6% max: -0.3%
tokio-webpush-simple
avg: -1.2% min: -1.6% max: -0.0%
helloworld-check
avg: -1.4% min: -1.6% max: -1.2%
deeply-nested
avg: -1.2% min: -1.4% max: -0.8%
encoding-check
avg: -0.8% min: -1.3% max: -0.3%
unify-linearly-check
avg: -1.0% min: -1.3% max: -0.8%
script-servo-check
avg: -0.6% min: -1.3% max: 0.0%
regression-31157-check
avg: -0.9% min: -1.2% max: -0.7%
script-servo-opt
avg: -0.5% min: -1.2% max: 0.1%
deeply-nested-check
avg: -0.8% min: -1.2% max: -0.7%
encoding
avg: -0.7% min: -1.1% max: -0.3%
issue-46449-check
avg: -0.9% min: -1.1% max: -0.6%
parser-check
avg: -0.9% min: -1.1% max: -0.8%
html5ever
avg: -0.5% min: -1.0% max: -0.0%
```
|
|
Provide better names for builtin deriving-generated attributes
First attempt at fixing #49967
Not in love with any choices here, don't be shy if you aren't happy with anything :)
I've tested that this produces nicer names in documentation, and that it no longer has issues conflicting with constants with the same name. (I guess we _could_ make a test for that... unsure if that would be valuable)
In all cases I took the names from the methods as declared in the relevant trait.
In some cases I had to prepend the names with _ otherwise there were errors about un-used variables. I'm uneasy with the inconsistency... do they all need to be like that? Is there a way to generate an alternate impl or use a different name (`_`?) in the cases where the arguments are not used?
Lastly the gensym addition to Ident I implemented largely as suggested, but I want to point out it's a little circuitous (at least, as far as I understand it). `cx.ident_of(name)` is just `Ident::from_str`, so we create an Ident then another Ident from it. `Ident::with_empty_ctxt(Symbol::gensym(string))` may or may not be equivalent, I don't know if it's important to intern it _then_ gensym it. It seems like either we could use that, or if we do want a new method to make this convenient, it could be on Ident instead (`from_str_gensymed`?)
|
|
|
|
… previously in the unstable core::num::Float trait.
Per https://github.com/rust-lang/rust/issues/32110#issuecomment-379503183,
the `abs`, `signum`, and `powi` methods are *not* included for now
since they rely on LLVM intrinsics and we haven’t determined yet whether
those instrinsics lower to calls to libm functions on any platform.
|
|
|
|
|
|
Fixes #45803
|
|
`nearest_common_ancestor()` uses an algorithm that requires computing
the full scope chain for both scopes, which is expensive because each
element involves a hash table lookup, and then looking for a common
tail.
This patch changes `nearest_common_ancestor()` to use a different
algorithm, which starts at the given scopes and works outwards (i.e. up
the scope tree) until a common ancestor is found. This is much faster
because in most cases the common ancestor is found well before the end
of the scope chains. Also, the use of a SmallVec avoids the need for any
allocation most of the time.
|
|
This code path is rarely hit, which likely explains why this bug hasn't
been detected before now. (I only noticed it via code inspection.)
|
|
Fixes #49690
|
|
|
|
Fix save-analysis generation with extern_in_paths/extern_absolute_paths
Fixes #48742.
|
|
|
|
Resolve them into field indices once and then use those resolutions
+ Fix rebase
|
|
|
|
Even more thread-safety changes
r? @michaelwoerister
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mem-categorization, coherence fix
make mem-categorization use adjusted type for patterns: Fixes #49631
do not propagate `Err` when determing causal info: Fixes #48728
r? @eddyb
|
|
r=michaelwoerister
Fix another circular deps link args issue
It turns out that the support in #49316 wasn't enough to handle all cases
notably the example in #48661. The underlying bug was connected to panic=abort
where lang items were listed in the `missing_lang_items` sets but didn't
actually exist anywhere.
This caused the linker backend to deduce that start-group/end-group wasn't
needed because not all items were defined. Instead the missing lang items that
don't actually need to have a definition are filtered out and not considered for
the start-group/end-group arguments
Closes #48661
|
|
|
|
|
|
Fixes #49631
|
|
Host compiler documentation: Include private items
Fixes #29893. Now that compiler documentation is being hosted, including private items seems sensible as these types are going to be being used by contributors working on the compiler.
However, including this means that doc comments that contain codeblocks with invalid Rust and can fail the documenting of a given crate (as evidenced by the changes in the second commit included in this PR). We'd need some way of ensuring that this cannot happen so that these failures don't cause documenting to fail. I'm unsure whether this change to documentation steps will cause this to happen already or if something new will be required.
r? @alexcrichton
|
|
It turns out that the support in #49316 wasn't enough to handle all cases
notably the example in #48661. The underlying bug was connected to panic=abort
where lang items were listed in the `missing_lang_items` sets but didn't
actually exist anywhere.
This caused the linker backend to deduce that start-group/end-group wasn't
needed because not all items were defined. Instead the missing lang items that
don't actually need to have a definition are filtered out and not considered for
the start-group/end-group arguments
Closes #48661
|
|
|
|
|
|
|
|
|
|
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](https://github.com/rust-lang/rust/issues/15872#issuecomment-338700138).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes #15872
|
|
This clarifies the intent of whether to emit deprecated lint or not.
|
|
If there is potential ambiguity after stabilizing those candidates, a
warning will be emitted.
|
|
Misc changes from my parallel rustc branch
r? @michaelwoerister
|
|
Deprecated forms of elision are not supported.
|
|
|
|
This commit adds a new attribute to the Rust compiler specific to the wasm
target (and no other targets). The `#[wasm_import_module]` attribute is used to
specify the module that a name is imported from, and is used like so:
#[wasm_import_module = "./foo.js"]
extern {
fn some_js_function();
}
Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
module in the wasm output file. Wasm-the-format includes two fields on all
imports, a module and a field. The field is the symbol name (`some_js_function`
above) and the module has historically unconditionally been `"env"`. I'm not
sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
like the ability to configure it!
The proposed ES module integration with wasm (aka a wasm module is "just another
ES module") requires that the import module of wasm imports is interpreted as an
ES module import, meaning that you'll need to encode paths, NPM packages, etc.
As a result, we'll need this to be something other than `"env"`!
Unfortunately neither our version of LLVM nor LLD supports custom import modules
(aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
will have support, but in the meantime this commit adds some primitive
encoding/decoding of wasm files to the compiler. This way rustc postprocesses
the wasm module that LLVM emits to ensure it's got all the imports we'd like to
have in it.
Eventually I'd ideally like to unconditionally require this attribute to be
placed on all `extern { ... }` blocks. For now though it seemed prudent to add
it as an unstable attribute, so for now it's not required (as that'd force usage
of a feature gate). Hopefully it doesn't take too long to "stabilize" this!
cc rust-lang-nursery/rust-wasm#29
|
|
This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.
The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.
The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).
To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).
|
|
Replace many of the last references to readmes
In particular, this removes the dep track readme, so it should not be merged before https://github.com/rust-lang-nursery/rustc-guide/pull/92
Fix #47935
cc #48478
r? @nikomatsakis
|
|
|
|
resolve `'_` in `dyn Trait` just like ordinary elision
r? @cramertj
Fixes #48468
|
|
|
|
Add crate name to "main function not found" error message.
Fixes #44798 and rust-lang/cargo#4948.
I was wondering if it might be cleaner to update the ui tests to add a simple `fn main() {}` for the unrelated tests. Let me know if you would prefer that.
|
|
cc #48468
|
|
|
|
|
|
Fixes #44798 and rust-lang/cargo#4948.
|