Community
Participate
Working Groups
if you have an unused parameter and you apply a quick fix to suppress warnings you get protected final void test(@SuppressWarnings("unused") int pExitCode) { } after this Eclipse editor says "unused" should be externalised So then you have to quick fix that with //$NON-NLS-1$ and you get protected final void test(@SuppressWarnings("unused") int pExitCode) //$NON-NLS-1$ { } This looks ugly (as if the annotation did not contribute enough ugliness). I have seen in other situations eclipse does not complain about "unresourced strings" inside annotations ?
Moving to core. We should indeed not flag strings used inside of @SuppressWarnings as non nlsed.
The filtering is done only for warnings. It is not done for errors. This should be fixed.
Did you set non-externalized string literal to error or warning? If you use a 3.2M1 build, it works fine for warnings, but when set to error, it is still reported. Please confirm your settings and provide build id.
The filtering of the non-externalized string literal inside annotations must be done earlier. If it is done only in the compilation result, it won't work when it is set to error, because the reference context has been tagged as having error and therefore it is not analysed. Philippe, I will review my changes to filter them in the parser. Hopefully I will be able to get enough context to do so.
The only way to get enough context in the parser is to remember the ranges of the annotations in the parsing. In order to do that properly, this means that the detection of non-externalized string literals has to be done in the diet parse and in the parsing of the method bodies. Right now the diet parse is sufficient. If we have to do it in the parsing of method bodies, this means that in invalid code it won't be possible to report all non-externalized string literals. Another solution would be to keep the existing code and do the filtering in the compilation result, but not tagged the reference context as having errors if the error is only a non-externalized string literal. We would then be able to report all non-externalized string literals even if the code is syntactically wrong and we could resolve the reference context even if contains non-externalized string literals. Philippe, which one do you prefer?
For the second option, we could use the same trick than for bug 107332. But we still need to make a distinction when filtering nls inside annotation' ranges and within annotation scopes. For example: public class X { @SuppressWarnings("nls") String s = ""; } In this code, when nls is report as an error, I don't want the error on the literal "nls", but I do want an error for the literal "". So we cannot simply reuse the support for SuppressWarnings to filter out nls errors/warnings inside annotation's ranges.
Created attachment 26404 [details] Proposed fix First draft. It is still using the suppress warnings support to filter out the nls errors/warnings. So it doesn't report an error for the literal "", but it shows how to handle the detection of nls literals in the code without tagging the reference context as having errors.
(In reply to comment #3) > Did you set non-externalized string literal to error or warning? > If you use a 3.2M1 build, it works fine for warnings, but when set to error, it > is still reported. > Please confirm your settings and provide build id. I use Eclipse 3.1 and non-externalized string literal is set to "warning"
Then if you use 3.2M1, your problem will be fixed. But we still need to find a good solution for the error case.
This bug also applies to @SuppressWarnings("deprecated") on the same platform Same thing happens and requires additional //$NON-NLS-1$
Are you using 3.1 or 3.2M1?
(In reply to comment #11) > Are you using 3.1 or 3.2M1? I have already mentioned I use 3.1.
My preference would be to not report the offending problem, rather than filtering it out in the end, due to side effects when ERROR severity is set.
I understand, but this would have an impact on performance and we would not be able to return the nls string literals warnings/errors where there are syntax errors. In order not to report the problem, we need to know if we are within an annotation (normal annotation, marker annotation or single member annotation). These annotations can be located on types, methods, fields or locals. So in diet mode, we could get them fine for types, methods and fields, but not for locals since we don't actually "parse" the method bodies when we are in diet mode. The detection of nls string literals is done during the diet parse to return them even if the code is syntactically wrong. If we move the code inside the parsing of method bodies, we would lose that information when we have syntax errors. Considering this, I believe we need to do this filtering before we report the problem. Did I miss anything?
If we decide that code with syntax errors might not provide these warnings, we could move the detection of code inside method bodies instead of the diet parse. Then this would allow us to "know" that the string is located within an annotation.
Fixed and released in HEAD. Regression tests in org.eclipse.jdt.core.tests.compiler.regression.ExternalizeStringLiteralsTest.
Verified for 3.2 M3 using build I20051031-0010
