Merged
Conversation
* Modified the TypePattern in order to handle SingleVariableDeclaration and VariableDeclarationFragment. * removed unwanted $NON-NLS$ tags * Incorporated the code review changes.
…nts (eclipse-jdt#2731) The changes especially include the scanner changes to recognize the markdown format and resolve, validate and report tags and references inside the markdown comments. * Fix failing formatter tests by changing tests. Tests are failing due to markdown being converted to Javadoc without a distinction from regular Javadoc. This needs to be addressed in DOM.
Currently there is no name for the ECJ Implementation of JavaCompiler. This sets the name so it is possible to identify the JavaCompiler as ECJ.
…lipse-jdt#2747) * Modified converterJCL for 22 - primarily for added tests * done some re-factoring in the ASTConverter in order to make the code more simpler.
eclipse-jdt#2743 (eclipse-jdt#2750) Make sure that compliance level is set regardless of the AST level. Also, this being a standard feature, preview flag is not required.
The tests were updated to compile with at least Java 1.8 and against Java 1.8 jcl library. See eclipse-jdt#2536
As noticed on the review, inlineJsrBytecode option makes no sense anymore and could be removed along with the related code. - Made the option enabled by default - Removed all the code paths for the case where the option was "off" - Updated tests to always assume the option is enabled. - made both JavaCore.COMPILER_CODEGEN_INLINE_JSR_BYTECODE and CompilerOptions.inlineJsrBytecode deprecated Note: CompilerOptions.inlineJsrBytecode field is left only in case some of the (non-API) clients used this field directly. Changing it will have no effect anyway as no code uses it in compiler. See eclipse-jdt#2536
There are few interesting observations: 1) The test fail didn't show up in jenkins. I can't see why. 2) The test fails now because an unexpected execution from BatchGenProcessor happens, which wasn't there before. 3) The MixedModeTesting.testAPTRoundingInMixedMode1() was added before BatchGenProcessor was added, and never run into the BatchGenProcessor code, it only used BatchGen1AnnotationProcessor. Now both processors are active, resulting in a duplicated output. 4) Both processors are active now because we enable annotation processing by default with 1.8 level projects (and required an explicit option for 1.4). For now I've simply updated test expectation. See eclipse-jdt#2536
After switching default compilation level to 1.8 few tests that were working on Java 17 JVMs started to fail because the code snippets used compile now properly. The test fail didn't show up in jenkins because Jenkins runs on Java 22 but the code snippets were tested only on Java 17 JVM's. See eclipse-jdt#2536
…clipse-jdt#2749) Unit test: This test represents a combination of explicit and auto modules with shared package prefixes which triggers the compiler to add a SplitPackageBinding as child of a PlainPackageBinding which should never happen. Fix: When combining packages bindings from different modules, an auto-module should consider all modules declaring the package, because it implicitly reads all modules and getAllRequiredModules() only works with explicit dependencies. Pending follow-up: eclipse-jdt#2764 fixes eclipse-jdt#2748 --------- Signed-off-by: Paul Pazderski <paul-eclipse@ppazderski.de> Co-authored-by: Paul Pazderski <paul-eclipse@ppazderski.de> Co-authored-by: Stephan Herrmann <stephan.herrmann@berlin.de>
Due to [Removal of Module jdk.random](https://bugs.openjdk.org/browse/JDK-83300050) number of modules and provides of java.base module change and the test assertions are adjusted accordingly. Fixes eclipse-jdt#2735
… (eclipse-jdt#2772) Basic changes to CompletionScanner to recognize markdown comment blocks and associated tests
…-jdt#2776) - Fix DefaultBindingResolver.isResolvedTypeInferredFromExpectedType() - restore some tests that were changed when the move to min Java 1.8 was merged Fixes eclipse-jdt#2775 --------- Co-authored-by: Stephan Herrmann <stephan.herrmann@berlin.de>
+ do expect ExplicitConstructorCall even in regular method Fixes eclipse-jdt#2782
Don't hide exceptions that cause test to fail with seemingly unrelated errors later. See eclipse-jdt#2766
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4.3.4 to 4.3.5. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@0b2256b...89ef406) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
I have an impression that JavaModel.getJavaProjects() that uses OpenableElementInfo to maintain children may sometimes return stale data because OpenableElementInfo is not synchronized and probably could be accessed from different threads (the volatile children field indicates that the original authors assumed multi-threaded access to that data). This could explain why we sometimes see absolutely fully unexpected test failures related to the Java projects state. See eclipse-jdt#2716
There are resource change events coming to JDT from non-UI thread by putting breakpoint at `org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(IResourceChangeEvent)`. Events are coming from different places, below incomplete list: - `org.eclipse.core.internal.resources.DelayedSnapshotJob.run(IProgressMonitor)` that is triggered both periodically and on few special cases (NB: **job has no family!**). Special cases are project deletion and creation, options change... Breakpoint at `org.eclipse.core.internal.resources.SaveManager.snapshotIfNeeded(boolean)` helps to see where are they coming. - `org.eclipse.jdt.internal.core.ExternalFoldersManager.RefreshJob.run(IProgressMonitor)` (NB: job has family `ResourcesPlugin.FAMILY_MANUAL_REFRESH`) - `org.eclipse.jdt.internal.core.JavaModelManager.touchProjectsAsync(IProject[])` (NB: job has family `ResourcesPlugin.FAMILY_MANUAL_REFRESH`) - `org.eclipse.core.internal.events.AutoBuildJob.AutoBuildOffJob.run(IProgressMonitor)` (NB: job has family `ResourcesPlugin.FAMILY_AUTO_BUILD`) It seem that adding `waitForManualRefresh()` at the end of `org.eclipse.jdt.core.tests.model.AbstractJavaModelTests.tearDown()` helps. Note: we can't unconditionally call waitForManualRefresh(), it should be always done outside of the code that holds workspace rule, otherwise we will run in deadlocks with other jobs... See eclipse-jdt#2716
PerProjectInfo with almost all fields being public is a big mess. Every thread can access every non final field at any time without any consistency checks etc. Let make all non final fields volatile so that they read at least the latest data, even if only partially consistent. The object inconsistency may appear because most of the fields are set in PerProjectInfo.setClasspath() in a non-atomic way, so readers who don't lock on PerProjectInfo may observe partially updated PerProjectInfo object. Ideally all the fields should be made private and accessed from dedicated synchronized methods on PerProjectInfo. See eclipse-jdt#2753 (comment)
org.eclipse.core.internal.resources.DelayedSnapshotJob.run(IProgressMonitor) is triggered both periodically and on few special cases. Special cases are project deletion and creation, options change... This job may create change events coming to JDT from non-UI thread, see org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(IResourceChangeEvent). To avoid sporadic test fails we should also wait for that job. Note: we can't unconditionally call waitForSnapShot(), it should be always done outside of the code that holds workspace rule, otherwise we will run in deadlocks with other jobs... See eclipse-jdt#2716
The list current returned by JavaCore.getAllJavaSourceVersionsSupportedByCompiler() is mainly/only used to either fetch the first or last element or test if a version-String is contained. Especially for the last operation a Set is a better choice regarding runtime. A SortedSet additionally also offers the methods first()/last(), which are semantically more expressive than calling List.get(0)/List.get(List.size()-1). Furthermore using a SortedSet would also better reflect the general semantic of the returned collection and element-access is usually not of interest.
Both options are still present in compiler/core code, but shouldn't be set to any other value as "error". For now we will ignore any provided values and use "error" by default. See eclipse-jdt#2536
That recently added API method can be replaced by JavaCore.getAllJavaSourceVersionsSupportedByCompiler().first() Follow-up on eclipse-jdt#2770
* Restructure switch expressions grammar aligning it with JLS terminology; Eliminate unnecessary calls outs from the automaton (-> instead of ::=); fold multiple consume rules into one by parameterizing; delete dangling non-terminals (ThrowExpression ...); deduplicate unnecessary distinct non-terminals (e.g `SwitchLabelExpr` vs `SwitchLabel` ...) * Replace the pair of tokens, first the synthetic `BeginCaseExpr` followed by '->' in switch rules with a single synthetic `CaseArrow`. The scanner will disambiguate whether a token '->' is `TokenNameARROW` used in lambdas or is a `CaseArrow` used in switch rules by checking if the automaton will shift `CaseArrow` or not. * DiagnoseParser's repair of a misclassified '->' will allow it to recover perfectly! Just suppressing the message will do. * Get rid of code engaging `VanguardParser` in reconnaissance missions for `yield` and '->' disambiguation. * Eliminate feedback from Parser to Scanner on co-ordinates of the case statement * Eliminate feedforward from Parser to SwitchStatement on whether it contains patterns, nulls etc; Let Switch discover it's self by itself :) * Declutter `SwitchStatement.resolve()` by simplifying control flow; streamline management of secrets; * Delete `SelectionParserTest12.java` as it is fully duplicated by `SelectionParserTest13.java`; Rename the latter to `SelectionParserTest14.java` and ensure it runs in the right compliance mode. Hook up this dangling junit to a parent * Tweak a failing test case in `PrimitiveInPatternsTestSH.java` to work around a bug elsewhere that was masked so far. eclipse-jdt#3265 raised as follow up. * Adjust a few tests that result in altered diagnostics due to grammar refactoring * Adjust test in `FormatterRegressionTests.java` and `ResolveTests12To15.java` to run at the right compliance levels
eclipse-jdt#2699) Introduce a new strategy (enabled by opt-in CompilationUnit.DOM_BASED_OPERATIONS flag) which, instead of using the ECJ-derived parser, uses ASTParser to create a DOM and then turns the DOM into a JavaModel structure. This has the benefit of: * Simplifying the code as an crawling DOM is usually simpler than dealing with lower-level parser * allowing other parsers as backend if ASTParser is configured for it
…expressions in a switch statement (eclipse-jdt#3275) * Fixes eclipse-jdt#3274
creation in switch block * Fixes eclipse-jdt#3276
…cks (eclipse-jdt#3281) * This has been disabled more than a decade ago!
…a case fall-through(eclipse-jdt#3286) * Fixes eclipse-jdt#3283
* use Set<String> * cache a unmodifiable copy * simplify PackageCacheEntry to record * add missing final/volatile modifiers * remove ClasspathJrt.PackageCache (only module names had been used) * don't calculate unused location of module.info * remove closeZipFileAtEnd (was always true when zipfile!=null) eclipse-jdt#3250
And remove duplicate code in ClasspathJrtWithReleaseOption.getModuleNames()
Throwing an Exception here currently causes more pain then just continuing. Ideally one would rework the getter JavaProject.getResolvedClasspath() to never modify the javamodel, but it's not clear how todo that in a compatible way. eclipse-jdt/eclipse.jdt.ui#1742
# Conflicts: # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/ClassFile.java # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/ast/RecordPattern.java # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/ast/SwitchStatement.java # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/lookup/LookupEnvironment.java # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/parser/Parser.java # org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/parser/Scanner.java # org.eclipse.jdt.core/codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java # org.eclipse.jdt.core/codeassist/org/eclipse/jdt/internal/codeassist/complete/CompletionScanner.java # org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom/ASTConverter.java # org.eclipse.jdt.core/dom/org/eclipse/jdt/core/dom/ASTMatcher.java # org.eclipse.jdt.core/search/org/eclipse/jdt/internal/core/search/BasicSearchEngine.java
This reverts commit 7a68c70.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.