generic will make the Trait non-object safe, so use a specific type
instead a generic instead.
```rs
// Examples of non-object safe traits.
trait NotObjectSafe {
const CONST: i32 = 1; // ERROR: cannot have associated const
fn foo() {} // ERROR: associated function without Sized
fn returns(&self) -> Self; // ERROR: Self in return type
fn typed<T>(&self, x: T) {} // ERROR: has generic type parameters
fn nested(self: Rc<Box<Self>>) {} // ERROR: nested receiver not yet supported
}
struct S;
impl NotObjectSafe for S {
fn returns(&self) -> Self { S }
}
let obj: Box<dyn NotObjectSafe> = Box::new(S); // ERROR
```
I'm not sure if it was intentional, but something that seemed to be
"Tuning" was written as "Turing", so I've corrected it.
If it's unnecessary, please close it 🙏🏻
When building the vsix file, it was necessary to execute the build
command before the package command.
As a result, the documentation has been updated!
Adds first `eslint-plugin-jsx-a11y` rule.
Had to comment out a couple of tests with TODOs related to evaluating
logical expressions and polymorphic components, but I think these are
largely edge cases for detecting validity of alt text. The most
important cases are covered.
This PR fixes the covered span (specifically the stop position) of
`eslint-disable-next-line` comments.
Note that the covered span is not very accurate in the case of
multi-line comments. For example, the start and stop positions of the
`eslint-disable-next-line` comment in the example below are marked in
comments.
```js
/* eslint-disable-next-line no-debugger --
* Here's a very long description about why this configuration is necessary
* along with some additional information
**/
// ^start
debugger;
// ^stop
debugger;
```
The stop position has an offset of one or two depending on the line
ending (\r\n or \n). I am not sure if this would be a problem.
Adds the `just new-jsx-a11y-rule` for bootstrapping
`eslint-plugin-jsx-a11y` linting rules.
One tricky thing about the tests in that repo is that the aren't
provided as array expressions
(e.g., `[case0, case1, case2, ...]`) but rather separate arguments to
`[].concat()`
(e.g., `[].concat(case0, case1, case2, ...)`). There is probably a more
elegant way to match
these expressions, but this is what I came up with.
The other thing I introduced in this PR is prefer Rust's raw strings
(`r#`) when generating the
test cases. Sometimes running `just new-*` spit out unescaped back
quotes, which caused issues.
